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1 0 INTRODUCTION 


In July of this year NASA successfully launched the first Earth 
Resources Technology Satellite (ERTS A). Early images from the ERTS Multi- 
spectral Scanner (MSS) indicate that the data will have an applications 
utility considerably beyond that anticipated. The quality of the MSS data, 
coupled with the repetitive and synoptic nature of its coverage, make it 
an excellent precursor to any subsequent manned or automated platform in- 
tended to routinely provide data to operational users. The ERTS experiment, 
in conjunction with experiments flown on Apollo, those planned for Skylab, 
and the ongoing NASA aircraft remote sensing experience, are pointing the 
way towards genuine utility of earth survey data. 

The departure point for this study was the assumption that the current 
experimental activity in remote sensing does, in fact, evolve into an envir- 
onment of beneficial and routine use of the data. This evolution is assumed 
to be well underway by the late seventies and nearing completion as the 
Space Shuttle becomes a useful tool for earth observations. The mam thrust 
of the study has been to define the requirements of the would-be operational 
users and to address the fundamental question, what is the nature of the 
processing systems required to convert remotely sensed data to useful infor- 
mation 7 
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2 0 SUMMARY AND CONCLUSIONS 


This report documents the conclusion of a nine month study addressing 
the ground data processing of remotely acquired earth survey data. The 
primary goal has been to define a conceptual approach to the design of a 
processing system(s) which would evolve early in the post-Skylab period and 
extend well into the Space Shuttle era ' A dominant theme of the study has 
been to define processing requirements of various user agencies in the con- 
text of operational management programs utilizing and depending upon the 
acquired data. The study assumes that there is continued need for, and 
benefit from, experimental research and development efforts, but that the 
principal contribution of remote sensing technology should be in supporting 
operational activities of agencies with well established jobs to perform. 
The difficult task then becomes one of quantifying the volume and nature 
of data to be processed and the techniques to be employed to generate 
useful information for these operational users. 

Study emphasis has been on developing a "unified" concept for the 
required ground system(s), capable of handling data from all viable acquis- 
ition platforms and sensor groupings envisaged as supporting operational 
earth survey programs. The platforms considered include both manned and 
unmanned spacecraft in near earth orbit, and continued use of low and high 
altitude aircraft. The sensor systems include both imaging and non-imaging 
devices, operated both passively and actively, from the ultraviolet to the 
microwave regions of the electromagnetic spectrum.* 

Motivation for performing the current study was provided by consider- 
ation of the following problems: 

first - in the area of manned systems, the post-Skylab "experiment" 
data processing is loosely defined 

second - in spite of considerable interest and activity on the part 
of would-be users of earth survey data, the requirements 
for data supporting operational activity are poorly iden- 
tified and rarely quantified 
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third 


- automated and man-assisted techniques for converting 
remotely sensed data to information are primarily 
topics of research (this situation essentially ex- 
plains the existence of the first two problems) 

fourth - design and development of a "unified" ground processing 
system for operational programs requires lead time of 
approximately 3 to 5 years 

fifth - evaluation tools do not exist to rapidly assess the 
impact on ground systems of evolving processing re- 
quirements for earth resources data 

Specific study objectives derived from the above motivation are* 

• survey, catalog, and analyze output data characteristics 
of sensors expected to be flight qualified in the time 
frame of interest 

• define preprocessing requirements generally attributed to 
unique characteristics or anomalies associated with the 
sensors of concern 

e structure a method for defining realistic operational 
user requirements for various remotely sensed data 
products 

• relate required data products to a set of modular pro- 
cessing functions to be performed by the ground system 
(onboard processing is considered only as it may impact 
the ground workload) 

e relate the set of modular processing functions to equip- 
ment types by which implementation of the functions may 
be obtained (equipment types considered include off-the- 
shelf and anticipated devices based on digital, electronic 
analog, photo-optical, and electro-optical principles) 

• develop a method for synthesizing candidate ground pro- 
cessing systems 

9 develop a simulation tool to evaluate competing candidate 
systems 

» select promising concept(s) 
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In performing the overall study, effort has been devoted to six major 
task areas: user requirements; sensor systems, processing requirements, 

techniques, and equipment, onboard processing implications, system perfor- 
mance simulation, and system synthesis and conceptual design. The first four 
of these areas are reported in detail in the contract Mid-Term Report, 

"Design Requirements for Operational Earth Resources Ground Data Processing," 
12 May 1972. The current report concentrates primarily on summarizing the 
users' requirements for data products, defining requirements for system 
design, synthesizing a conceptual system approach and developing a System 
Performance Simulation. The interrelation of the study objectives and the 
major task areas is shown in Figure 2-1. 

Overall study conclusions are summarized below by major areas of 
concern. 

USER REQUIREMENTS 

Conclusion 1 - Meaningful requirements for remotely sensed data 
can best be obtained by concentrating on a user community com- 
prised initially of non-NASA, federal agencies (e.g., USGS, USDA, 

EPA, NOAA, etc.) as opposed to a lower tier of would-be users 
(i e., the "man-i n-the-street," or the individual research 
investigator). This conclusion follows principally from the 
study's preoccupation with operational utility, which in turn 
dictated synthesis of management programs representing a charter 
for servicing, monitoring, controlling or providing a product to 
some area of socio-economic activity. The issue then becomes 
one of substituting remotely acquired data for current conven- 
tional sources of data, or augmenting the conventional infor- 
mation by the additional use of remotely sensed data. 
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Conclusion 2 - In analyzing a number of postulated operational 
management programs, it is concluded that the number of uniquely 
different data products (those things that the ground processing 
systems must produce) that agencies can effectively use in their 
various decision making and management functions is relatively 
small (i.e., less than twenty). The small size of this family 
of data products is significant in determining the degree of 
"service" oriented processing that a single agency might perform 
for others. 

Conclusion 3 - The predominance of requirements for data products 
by the management programs considered can be simultaneously 
satisfied by input imagery data characterized by, approximately 
weekly coverage of the continental United States, with an effec- 
tive ground resolution approaching 50 feet, with four to six 
spectral bands through the visible to the near infrared wavelengths. 


SENSOR SYSTEMS 

Conclusion 1 - Spatial resolution ranging between 50 and 100 feet 
is obtainable from ERTS altitude (^ 500 n. mi.) in the 1975-85 
time frame. Implications of this high resolution will be longer 
optics focal length, larger focal plane format (assuming approxi- 
mately 100 n. mi. swath width is maintained), and heavier instru- 
ments . 

Conclusion 2 - Multispectral imagers can best be implemented 
with the solid state array "push broom" technique to eliminate 
mechanical movement of optical components with a resultant 
step towards long term reliability. 

Conclusion 3 - Framing photographic cameras will continue to 
have utility through the next 5 years but will eventually be 
phased out of operational systems as electronic scanners approach 
the necessary spatial resolution. 
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PLATFORMS 

Conclusion 1 - The circular, polar, 500 n. mi. sun-synchronous 
orbit of ERTS inherently provides near ideal coverage potential 
for operational missions {particularly if more than one space- 
craft is phased within this orbit to give repetitive frequency 
below 18 days). The implication of this desired orbit coupled 
with the expected payload weight of the required platforms (i.e., 
well in excess of the 2,000 lb ERTS class payload) will dictate 
the use of the Space Shuttle as the launch vehicle for both auto- 
mated and manned earth survey platforms (the latter possibly being 
a manned laboratory on the shuttle orbiter eventually evolving 
to a fully modular space station). 

Conclusion 2 - The Space Shuttle may find its greatest role in 
earth resources in operational maintenance and replacement of 
the automated systems needed for sustained, long term data 
acquisition. 

Conclusion 3 - The most promising aspect of a manned orbiting 
earth resources platform is the role that man might play in 
selective data acquisition and screening, and decision verifi- 
cation supporting ground based analysts. This latter role 
supposes that the onboard analyst might have access to higher 
quality imagery (eg., photo quality processing) and therefore 
be able to confirm things in the imagery that the ground analysts 
only suspect. 

Conclusion 4 - Aircraft will see continued usage into an oper- 
ational era, both as a source of "ground truth" data and as 
an acquisition platform which can be flexibly and selectably 
depl oyed . 
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DATA PROCESSING TECHNIQUES 

Conclusion 1 - Machine-assisted classification of ground objects 
based on spectral information content promises to reduce the 
manual interpretation time currently required to analyze and 
process imagery. 

Conclusion 2 - Spectral signature classification techniques will 
continue to have a high degree of dependence on "training" site 
ground truth information and are therefore inherently "adaptive" 
in nature. The real issue is whether or not the adaptive processes 
can be highly automated or whether they continue to require the 
assistance of men for the adaptive training. 

Conclusion 3 - There are a number of viable data products required 
by users that do not depend upon the eventual success of automatic 
classification schemes (e.g., photomaps, overlays, thematic maps, 
statistical summaries, change discrimination, etc.). This is a 
significant point in that there is technical risk associated 
with the current approaches to automatic classification based 
solely on spectral content (man as a classifier uses a subtle 
combination of several types of information content within an 
image, eg., spatial relationships, tonal properties, textural 
characteristics, etc.). The implication of this conclusion, 
being, that in the worst case if automatic techniques did not 
mature, it is still possible that cost-effective applications 
exist. This latter contention is further reinforced by the 
estimate of the total data volume to be processed to satisfy 
user agencies, the lack of urgency to process it and the 
recognition that it is not totally unreasonable to rely heavily 
on trained, human interpreters to handle the operational work- 
load. 
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Conclusion 4 - Removal of both geometric and radiometric dis- 
tortion from imagery can best be performed by utilizing ground 
scene reference targets as opposed to mathematically modeling 
the individual error sources and then inverting these models 
to correct the imagery This would take the form of well sur- 
veyed ground control points for geometric corrections (currently 
employed by the ERTS processing facility at GSFC), and some type 
of calibrated, intense light source on the ground for radiometric 
corrections . 

PROCESSING HARDWARE 

Conclusion 1 - The flexibility of digital image processing makes 
it the leading alternative for most forms of processing. The 
necessary throughput speed required will most probably be obtained 
by specialized, solid state digital modules with a high degree of 
parallel execution This type of digital implementation is also 
the leading candidate for both aircraft and spacecraft onboard 
processing 

Conclusion 2 - Both optical processing (Fourier transformation and 
spatial frequency filtering) and electronic analog computing cur- 
rently show limited potential for consideration in operational 
ground systems 

Conclusion 3 - Ground processing systems will have a continued, 
long term dependence on certain aspects of high quality photo 
processing. This will probably remain true even if photographic 
cameras are eventually phased out as primary sensors. This con- 
clusion could be negated, however, by a significant improvement 
in either electron or laser beam film recorders with self con- 
tained "developing" and copying capability. 
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TOTAL GROUND SYSTEM 

Conclusion 1 - The limited size of the family of required data 
products tends to promote the idea of a single agency providing 
those products to the user agencies as a service. 

Conclusion 2 - The number and geographical distributon of these 
self contained "service processing centers" should be based on 
efficiency and convenience of interface with the users. 

Conclusion 3 - A "unified" system which handles data from a 
variety of data platforms and sensor types appears technically 
feasible. 

Conclusion 4 - Distribution of data products from the service 
centers to the user agencies can be through normal mail or 
courier services (i.e., on the order of one to three days 
response) . 

GENERAL 

Conclusion - NASA must advocate and promote the use of remotely 
acquired data for operational utility Many problems remain 
concerning details of operational procedures and techniques and 
these can best be solved by NASA helping to demonstrate the 
operational benefits of the earth survey program. This conten- 
tion is in recognition of the communication gap that normally 
exists between application specialists (i.e., agriculturists, 
foresters, etc.) and the NASA technology specialists; and the 
observation that many agencies need to be shown more than just 
the spark of an application idea stemming from a principal 
investigator's research. Instead, the agencies need to be 
shown the complete system costs of going operational, in order 
that these may be measured against the expected benefits In 
short, the technology does not appear to be the limiting fac- 
tor, but rather the details associated with an operational 
system 
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3 0 REQUIRED DATA PRODUCTS 


This section contains a summary description of the data products that 
are commonly required by interpreters and analysts engaged in the earth 
sciences. The detailed management functions from which this summary is 
derived are included m the Mid-Term Report. 

3 1 User Requirements Analysis 

The prime interest throughout this study was to develop an understand- 
ing of the requirements imposed upon the ground data handling system by 
operational resource management programs Therefore, considerable attention 
was given to the current activities of Federal agencies charged with the 
management of natural resources, and the information needs of these agencies 
not currently satisfied by conventional data sources. 

There is a marked lack of information which definitively outlines the 
requirements of the agencies for remotely sensed data. This is understand- 
able since this technology is viewed as offering promise m several areas, 
but commitments to operational utility must await validation through 
experience with ERTS, EREP and aircraft data. Furthermore, it must be 
noted that until considerable sophistication is developed, statements of 
requirements will reflect management needs (e.g., assessment of the acreage 
of a particular crop) and probably contain little information concerning 
basic data requirements (e.g., resolution) or processing (e.g., geometric 
corrections) . 

An analytical framework was needed which would allow the study to 
push ahead by working around the lack of defined requirements. The basic 
requirements of this framework were: 

• It should bound the requirements for data products 

• It should facilitate ready evaluation of processing 
requirements accruable to specific stated requirements 

The basic technique developed in the study is outlined Figure 3-1 
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Figure 3-1. User Requirements Methodology 
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The potential applications for remote sensing technology which were 
selected for evaluation were all concerned with the management aspects of 
natural resources, these applications were deemed to be potentially feasible 
based upon successful research efforts and projected state-of-the-art for 
remote sensing technology. The applications were organized into the follow- 
ing programs* 

• Hydrological Resources Management 

• Geological Resources Management 

0 Agricultural Resources Management 

9 Forestry and Rangeland Resources Management 

o Coastal Zone Management 

» Urban Dynamics Management 

a Environmental Resources Management 

The large number of management functions contained in these synthetic 

programs are described in the Mid-Term Report of this study with respect 
to requirements for 

• Resolution 

• Frequency of Observation 

a Swath 

8 Spectral Region 

a Sophistication of Processing 

a Areal Extent 

In addition, preliminary assessments of data products for the program are 
provided in the Mid-Term Report. The remainder of this section will be de- 
voted to general observations about the programs considered, as related to 
the feasibility of defining a minimum set of required data products. 

There is a large number of applications for which observation frequen- 
cies on the order of one to two weeks (i.e., one or two spacecraft in ERTS- 
like orbits) are entirely satisfactory. However, the operational utility 
of ERTS data is severly hampered by the available resolution. The technology 
for increased resolution is available, but operational utility will require 
considerable work in tradeoffs of payloads and platforms. The fact that 
operational utility of the data is "enticingly near" suggests that attention 
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must be given to developing econometrically sound applications programs. 

This will likely require development of a system for a multiplicity of 
management applications. It is unlikely that the applications will group 
into the rather "clean" management programs of the Mid-Term Report, rather, 
a single system will support elements selected from those programs. The 
foregoing argument is further manifested in material presented m the Mid- 
Term Report relating to commonality of requirements among various manage- 
ment functions. 

3.2 Data Products 

The earth sciences are largely non-mathematical and to some extent 
empirical in nature Considerable emphasis is placed upon the intuitive 
and subjective processes of a trained analyst or interpreter. The classi- 
cal discipline of photogrammetry, which borders on being an art form, 
provides the basis for much of the interpretive work in earth resources 
Figure 3-2 describes some of the more frequent analytical modes employed 
by imagery interpreters. The various aids or presentation types most com- 
monly used are shown for the various modes. There are undoubtedly unlimited 
variations on these analytical modes due to the inherently subjective nature 
of the analysis processes, however, it is believed that the number of useful 
aids to interpretation, as well as the media of presentation, are relatively 
limited. 

The remainder of the section describes a set of these interpretive aids 
or data products. An attempt was made to define the smallest set of products 
commensurate with satisfying a majority of the projected analytical needs. 

The following is a list of these data products grouped according to output 
media: 

e Photographic 

Photomaps 

Prints 

Transparencies (including overlays) 

® Plotted 

Thematic Maps 

Statistical 
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ANALYTICAL MODE 

INTERPRETATIVE AID 

IMAGERY IS USED REPEATEDLY FOR PLANNING 
CONSTRUCTION, ASSIGNING WORK CREW, 
ETC 

PHOTOMAP 

IMAGERY IS USED TO SUPPORT VISUAL CHANGE 
DISCRIMINATION. COMPARISON BASE MAY BE 
MAPS OR OTHER IMAGERY. 

OVERLAYS (TRANPAR- 
ENCIES OR ADJUSTED 
SCALE PRINTS) 

IMAGERY IS USED IN PHOTOGRAMMETRIC PRO- 
CESSES FOR MAPPING OR TO MONITOR RATE 
OF MOVEMENT 

GEOMETRICALLY REFER- 
ENCED SPATIAL 
MEASUREMENTS 

APPLICATION IS CONCERNED PRIMARILY WITH 
INSTANTANEOUS SPECTRAL OR TONAL 
QUALITIES 

GEOMETRICALLY REFER- 
ENCED SPATIAL 
MEASUREMENTS 

IMAGERY PROVIDES SOURCE OF DATA TO SUP- 
PORT PREDICTION OF FUTURE STATES. 
TRANSFORMATION OF DATA TO COMPATIBLE 
UNITS AND CALIBRATION/CORRELATION WITH 
OTHER DATA MAY BE REQUIRED 

, INPUT FOR MATHEMATICAL 
MODELS 

APPLICATION REQUIRES VISUAL ASSOCIA- 
TION OF METRIC DATA DERIVED FROM IMAGERY 
WITH OTHER DATA TYPES 

THEMATIC MAPS 

INFORMATION CONTENT IS CONTAINED IN 
OVERALL TRENDS AND PROPERTIES OF THE 
ENSEMBLE OF METRIC DATA OF THE IMAGERY 

STATISTICAL SUMMARIES 

INFORMATION CONTENT IS IN CHANGES 
FROM A GIVEN BASE SUBTLETY OF CHANGES 
OR DATA VOLUME DICTATES AUTOMATED 
PROCEDURES 

AUTOMATIC REPORT OF 
CHANGES 

APPLICATION REQUIRES ASSESSMENT OF AREA/ 
EXTENT OF IMAGED REGION OF SPECIFIC 
PROPERTIES 

AUTOMATED INVENTORY 


Figure 3-2. Analytical Modes 
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9 Recorded 


Spectral Measurements of Photographic Imagery 

X-Y Locations of Features in Imagery 

High Density Digital Tapes 

Computer Compatible Tapes (including possible inputs to 

mathematical models) 

Specialized Program Tapes 
• Tabulated 

Inventory Summaries (includes change discrimination as a 

special case) 

Statistical Data Sumiaries 

Production Summaries 

These products are discussed in more detail below; the primary emphasis in 
the following material is in describing the attributes of the various 
products which determine the specifications for processing for specific 
users 

Photographic Products - The earth sciences depend heavily upon photographic 
products to serve both as a direct source of information and as an inter- 
pretative aid in understanding other measurements. 

Prints and transparencies can be derived from film exposed in the 
onboard optical train or film exposed according to characteristics of elec- 
tronic signals. This latter category could include exposure in accordance 
with the results of sophisticated classification schemes (e.g., "color corn 
yellow"). These products may require spectral slicing in which the film is 
exposed to a selected spectral range, or accordingly color composites may be 
required in which the various color layers are exposed using successive, 
registered frames representing individual spectral ranges. Special cases 
may require adjustment of tone and contrast. The overlay tools are trans- 
parencies. The attributes which must be specified by a user of photographic 
products are’ 
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o Emulsion 

e Positive or Negative 

• Instructions for Tone and Contrast 

• Colors for False Color Assignment 
9 Geometric Fidelity 

• Photometric Corrections 

• Transparency or Print 

• Any Cropping Bounds 

• Principal Point 

9 Any Registration Base 

• Scale 

Photomaps are map! ike products which are based upon photography. All 
of the above photographic attributes are required for specification includ- 
ing instructions for 

• Gridding 

a Annotation 

Plotted Products - The earth sciences use plotted products to better under- 
stand data and to provide the basis for visual correlation of imagery with 
other knowledge. 

The term "thematic maps" is commonly used to describe two data products* 

a Extracted themes (e.g., soil) displayed on an appropriate grid 
e Plots of summarized data presented on maps or photographs 

The first category is actually a photomap described earlier, and throughout 
this report "thematic map" will refer to the latter category. 

The information which is summarized can be based upon imagery data. 

For example, isopleths could be plotted on a map connecting points of like 
spectral response from a given channel. Also, the information to be 
summarized could be obtained from other sources and displayed on imagery. 
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For example, isopleths of temperature readings collected in an estuary at 
the time of an underflight (conceivably, an agency requiring such a product 
could be required to maintain the data base of external data) could be 
plotted. A variety of statistical routines are required to support a gen- 
eral thematic mapping capability, with the variation from a normal statis- 
tical capability being the ability to display the results of a "moving 
window", i.e., the statistical properties of data points lying within a 
square defined by corner ticks throughout the imagery. Several presenta- 
tions are normally used including pie plots, post plots, vectors and 
contours. The media upon which the information is plotted may include 
paper, acetate (for overlays) and photographic ^prints . The attributes 
which must be specified for these products include: 

9 Data to be summarized 

• Plotting base 

• Summary to be made 

9 Form of presentation 

• Media 

e Coordinate frame of data 

o Coordinate frame of plotting base 

Statistical plots may be required to provide insight into the proper- 
ties of raw data and data which has been grouped with a classification 
scheme. To fully specify these plots (normally histograms and scatter 
diagrams) the following information must be provided 

• The space to be plotted 

8 Ranges for histograms 

Recorded Products - Some agencies will hve capabilities for computer 
analysis of imagery data. The ground data handling system would provide 
computer tapes to be used by these facilities. 
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Precision spectral measurement of products could result from the use 
of standard densitometric and colorimetric techniques using either electronic 
or photographic film as the basic data Such a data product might be re- 
quired if applications are developed which determine physiological/physical 
parameters as directly functional to emulsion response. 

Attributes would include: 

• Spectral range of interest 

• Grid distribution of measurements 

• User computer tape requirements 

X-Y locations of features in imagery are included to account for support 
to applications requiring photogrammetric processes. These measurements 
could be used to monitor the movement of features (e.g., ice flows) or in 
mapping 

Attributes include: 

• Features of interest 

o Desired precision 

9 Desired reference frame 

High density tapes may be required for either raw data or data pro- 
cessed for certain corrections. 

Attributes include. 

• Level of radiometric and geometric fidelity 

e User equipment requirements 

• Requirement for supporting data 

Computer compatible tapes would have these same attributes. 
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Special program tapes are included as a product based upon an assump- 
tion of the capabilities of the processing facility(ies) . It would appear 
to be safe to assume that a facility would have available a multiplicity 
of digital computer algorithms which can be linked together in a flexible 
fashion. Furthermore, it may be assumed that there will be user agencies 
with computer capabilities to be used m the analysis of data. Conceiv- 
ably, a service facility could develop a computer program tape which has the 
the necessary algorithms properly sequenced to serve the needs of the user 
agency The information required to specify this product includes: 

• The specific requirements for processing 

• The raw data 

e The user agency equipment 

Tabulated Products - User agencies may require computer printouts of analy- 
sis results and possibly some form of transaction summary. Inventory 
summaries would result from the use of classification schemes, but addition- 
al information might be required. This information could include total 
area for each category or individual areas described by center location, 
areal extent and classification Requirements for specification would 
include: 

« Categories to be identified 
t Location accuracy 

9 Accuracy of areal calculations 
9 Specific form of output 

Statistical data summaries would utilize standard statistical algor- 
ithms, Specification requirements would include. 

t Parameters to be summarized 

9 Statistics to be used 

e Output format 

Production summaries or cataloges would include description of data 
received, quality of data, corrections effected on data, products generated, 
and disposition of raw data. 

Figure 3-3 illustrates the above family of data products and the 
respective media options. 
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Operational Utility - The processing systems' primary function would be to 
routinely produce data products for a user agency(ies) that has a specific 
chartered job to perform (i e., a federal agency which must monitor, con- 
trol, or provide a service or product for some area of socio-economi c 
concern), and who needs the data products to assist with management and 
planning functions associated with this job. Implied within this objective 
is the requirement to design a system with a throughput capability which is 
derived from a basic concern of the user agencies timeliness and response 
requirements. Additionally, the dedication to operational support inher- 
ently implies that the overall system operation will be cost-effective when 
compared to alternative or conventional methods of accomplishing the users' 
management functions (Note. The issue of cost-effectiveness or cost/bene- 
fits is outside the scope of the current study but it was the intent of 
this study to lay the foundation for subsequent analysis of costs and 
benefits to the would-be user agencies). 

Interagency Compatibility - The question of geographical distribution and 
NASA/non-NASA management of ground data processing facilities will ulti- 
mately be resolved by consideration of many factors, both technical and 
non- technical . One objective, however, would clearly be to build in 
systems compatibility between any NASA processing facilities and those of 
other agencies being serviced or supported. This objective should go be- 
yond simply input/output format and media compatibility to include 
transferability of software programs and modular processing components. 

Growth and Flexibility - This objective can best be stated as the require- 
ment for a truly modular system in which both software routines and 
processing logic modules (both analog and digital) and equipment types are 
easily replaceable or expandable with minimum impact to the overall system 
structure. 

4.2 Functional Requirements 

Consideration of the above objectives, and extrapolation from current 
experience being obtained at MSC and GSFC leads to the following functional 
design requirements: 
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• Input Flexibility - the system will be required to 
accept imagery data in various formats and media 
(eg, digital/analog tapes, film transparencies, 
etc ) and to reformat and convert this data to any 
other usable media or format (e.g , computer 
compatible tapes) at any desired point within 

the overall processing stream. 

9 Correction and Calibration - the system must employ 
workable and practical correction techniques to re- 
move distortion from the source data. A prime 
example is the current difficulty of successfully 
modeling all of the major sources of geometric 
distortion and geodetic positional error in the 
ERTS MSS and RBV data, and the practical alternative 
that was adopted by GSFC in the use of ground con- 
trol points for geometric correction. 

9 Adaptive Correction - provision should be made for 
selecting the degree of geometric and radiometric 
correction necessary based on initial trials with 
the spectral recognition and classification pro- 
cessing subsystems (necessary only in those cases 
for which recognition and classification are a 
necessary step to arrive at a desired data product). 

9 Multistage Correlation - the system will be required 
to correlate and register image data sets which are 
acquired by the same platform at different times 
(temporal registration), different platforms at the 
same times (scale, frame size and central point 
differences) and different platforms at different 
times. This registration could be considered to 
approach a worst case problem when low altitude, 
high resolution aircraft photographic imagery taken 
at a given time is to be used in conjunction with 
high altitude (~ 500 n. mi.) satellite multispec- 
tral scanner data of low resolution acquired at a 
different time. 

• Adaptive Classification - techniques for signature 
recognition and classification of ground objects 
based on spectral information content currently 
show a strong dependence upon ground truth or 
training sites for adaptive adjustment of the 
various algorithms and logic employed; the real 
issue being the feasibility of automatically 
providing the adaptive feedback versus continued 
use of man-in-the-loop as an on-line analyst for 
purposes of adaptation. A system requirement is 
the provision for this adaptive training cycle; 
irrespective of how it is eventually implemented. 
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e Manned Interface - for the training function described 
above, and for other purposes of monitoring, screening 
control, and interpretation, there exists requirements 
for information display to a human operator situated 
in both an on-line (typically interacting with digital 
or analog computational subsystems) and an off-line 
mode (i.e., interpreter at an optical projection 
viewer) . 

• Limited Data Management - a requirement exists pri- 
marily for short term data storage and retrieval 
for the purposes of calibrating and correcting sub- 
sequent data processing. Stated in this way the 
above implies, first, that data retention for the 
purposes of change discrimination (i.e., detection 
of change in the state of a ground scene of interest 
over a specified time period) would primarily be the 
responsibility of the ultimate user agency and as 
such is not considered an "output product" of the 
processing system; second, data retention and cata- 
loging for the purposes of centralized archiving 
and general dissemination to the public will continue 
to best be performed in a functionally separate fac- 
ility (e.g., the USGS/EROS Sioux Falls Data Center). 

0 Data Product Diversity - the processing system will 
be required to facilitate the generation of viable 
data products at many intermediate levels of data 
processing. This requirement is in recognition that 
many useful products exist that require limited 
processing or correction short of that possible 
by the system. An example would be producing an 
image copy m a single or composite spectral band 
for which no stringent radiometric corrections were 
required (e.g., a product intended for a photo 
interpreter interested in manually measuring the 
areal extent of a known and easily recognizable 
ground class). 

4.3 Processing Alternatives 

The best current example of a capability to produce remotely acquired 
imagery is represented by the NASA Earth Resources Technology Satellite 
(ERTS) launched July 24, 1972. This platform can produce over 9,000 separ- 
ate images within a weeks time, each representing a ground scene 100 n. mi. 
by 100 n mi . A single spectral band and its associated frame of Multi- 
spectral Scanner (MSS) imagery represents over 50 million bits of data 
( ~ 7.5 million picture elements/frame at an 7 bit encoding level). 
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The MSS total output data rate (for 4 spectral bands) is approximately 
7 M bits/sec, and this one instrument is capable of operating essentially 
continuously with an expected lifetime of over one year 

The message implied in a high data rate capability such as the 
experimental ERTS would appear to be: 

First: any future platform evolving from the ERTS 

experience intended for operational utility 
will desirably employ highly selective data 
acquisition methods (i.e., turn the sensors 
off periodically based on intelligent guide- 
lines stemming from a consideration of how 
much data can effectively be converted to 
information required by user agencies). 

Second* given that an acquisition platform can be 
controlled to collect only operationally 
meaningful data, it is highly probable 
that the remaining data volume and trans- 
mission rates will be sufficiently large 
to dictate all possible efficiency in 
achieving the necessary ground system 
throughput and responsiveness. 

In responding to the concern for high system throughput, the basic 
dilemma that arises in selecting a processing approach is that of digital 
image processing versus some form of analog computing or optical processing. 
The flexibility inherent in pixel by pixel manipulation possible through 
digital techniques has to be weighed against theoretically faster approaches 
involving electronic analog computing (with an associated inflexibility in 
implementing logical statements) and against the fundamentally parallel 
nature of optical processing (i.e., spatial frequency filtering via lens 
transformation and optical filters for image enhancement) with its associ- 
ated "instantaneous" throughput and considerable inflexibility The above 
alternatives are currently represented by the following options: 

1) General Purpose Digital Processors - typically large 
computers such as an IBM 360/75, Umvac 1108, or 
CDC 6500 in which the logical statements and sub- 
routines are programmed through conventional software. 
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2) Specialized Hard Digital Components - digital 
logic implemented by a network of solid state 
electronic components organized typically with 
a high degree of modularity, frequently to the 
logical operation level (i e , add, and/or, etc.) 
This approach offers primarily the advantages 

of higher processing efficiency in sequential 
operations by eliminating or minimizing execu- 
tive control overhead and communication with a 
central processing unit, and the possibility 
of many identical parallel circuits to achieve 
high throughput The obvious disadvantage is 
the difficulty of reprogramming the "hardwired" 
black boxes or the cost and time of adding new 
boxes. 

3) Electronic Analog Computers - most frequently 
implemented as a hybrid system where a relatively 
small digital computer is used to compute and 
control the setting of switches and potentiometers 
to initialize or set-up the analog circuitry. 

4) Electro/Optical Processing - this may be con- 
sidered as essentially a recording or display 
technique in which some effective "processing" 
is performed by variably biasing the electronic 
functions Typically, an input image is scanned 
by a vidicon tube with a small beam spot size 
(representing the resolution element desired), 
corrections or biases are computed either 
digitally or with analog circuitry, and a new 
image is written or displayed by imposing the 
corrections on deflection commands. 


5) Photo/Optical Processing - the complete range of 
manipulations, corrections and enhancements 
possible through conventional photographic film 
processing. 

6) Optical Processing - primarily based on the trans- 
formation properties of lenses and spatial frequency 
filtering by physically placing optical masks in the 
transform plane to eliminate structured noise (e g., 
a herringbone pattern in a raw image introduced by 
cyclic interference with the sensor from other on- 
board components) or to sacrifice certain selected 
spatial structure information to enhance other 
information of interest. 
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The one obvious additional option to the above list is the practical com- 
bination of any of the six approaches in a way that could hopefully 
maximize the utility gained from the attractive features, and minimize 
the penalties arising from the weak features, of each This then, is the 
fundamental task of beginning conceptual design and synthesizing the 
ground processing system. 
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5.0 SYSTEM SYNTHESIS APPROACH 


The approach to synthesis and design of a system concept is presented 
in this section. The intent is to organize the major system functions com- 
prehensively and to generalize the system structure where possible. By 
this approach it is hoped to provide an organized way of thinking about the 
processing system structure, and its necessary functions and equipments. 

This, in turn, may facilitate inclusion of new and advanced processing 
techniques as they develop, as well as accommodation of current methods. 

In a sense, the approach presented can be considered as an aid to the sys- 
tem designer. In view of the fact that there exists many alternatives with 
many design decisions to be made, the intent has been to minimize the diffi- 
culty of these decisions by clearly identifying the practical options. 

The overall design process can be viewed as having four major phases: 
the designer exercises the general approach described within this section; 
the designer selects a specific functional flow and associated equipment 
(described step-by-step in Section 5.5), the designer evaluates the perfor- 
mance of his "point design" using the System Performance Simulation (Section 
6.0); the designer repeats the previous phases through an iterative process 
until a system design is found which satisfies his performance requirements. 

5.1 Input Data Workload 

An obvious and fundamental requisite exists when approaching the design 
of a ground processing system, the designer must know what the system is to 
produce. He must either have, or postulate, an explicit description of the 
output data products and their characteristics. Obtaining this quantita- 
tive information implies defining the attributes of data products through 
an extensive dialogue with the would-be user agencies, as discussed in 
Section 3.0 "Required Data Products." 

Given that definition of the data products is achievable for a given 
design case; two basic alternatives exist for providing an input raw data 
workload (nature, volume, and frequency of the source sensor data) to the 
system. 
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Option 1 - assume that the data acquisition capability 
of an existing or planned platform drives 
the ground system. An example would be to 
assume that the ERTS A RBV and MSS supplied 
the input imagery and to eventually ask the 
question through design evaluation, can the 
required output data products be satisfac- 
torily generated with this assumed input? 

Option 2 - work backwards from a knowledge of the 
required products (and their attributes 
as defined in Section 3.2) to an estimate 
of what the input data should be (an 
estimation method is described in Section 
5.5). This estimate would then be refined 
through the design and evaluation iterative 
process . 

The implication of exercising this second option would appear to be 
an emphasis on asking the logical question, how much data do I need?; as 
opposed to asking, how do I process and utilize all of the data the existing 
sensors are capable of generating? Additionally, this approach permits the 
use of the performance simulation to effectively specify the characteristics 
of future sensor systems and platforms. This latter utility would appear to 
be both timely and appropriate in view of the rapid advances in sensor 
technology and output capacity, relative to the technology for processing 
the data. 

5.2 System Functional Organization 

Figure 5-1 illustrates the top level functional organization of an 
image processing system. This figure shows the interrelation of six major 
functional categories* 

preparation and conversion 

correction 

correlation 

manipulation 

classification and recognition 
output products 
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Figure 5-1. Functional Organization of an Image Processing System 









These categories are considered to be the primary functional areas 
through which data would flow in a high throughput, operationally oriented 
system. To a first approximation the flow may be considered to move left 
to right, from preparation and conversion to classification and recognition, 
with a progressively increasing sophistication and difficulty of processing. 
Exit from this progression should be considered to be possible at any inter- 
mediate point, resulting in a viable output product 

The above six major functional categories are supported by the 
functions of "manned interaction" and "data management." The importance 
of these two functions is minimized only in that they are not envisioned 
as contributing to the high throughput aspect of production of data products. 

Figure 5-1 does not attempt to depict the many alternative paths 
possible, or the feedback iterative loops.' It only attempts to provide 
a structure and simplified flow for the major categories of processing 
functions. These categories are, however, believed to comprehensively 
accommodate any meaningful form of image processing. The following section 
attempts to identify most of these meaningful operations within the major 
categories and describes them as "modular processing functions." 

5.3 Modular Processing Functions 

A set of functions within the above categories has been defined 
according to the following criteria: 

First - the functions should be modular and somewhat 
equivalent in scope (i e., the functions 
should be defined at a discrete processing 
step level and this level should represent 
the smallest divisible entity in terms of 
image processing, where possible) 

Second - the functions should be initially defined 
independently of the equipments or devices 
by which they might be implemented or per- 
formed 

Third - an attempt should be made to include all 

probable processing functions irrespective 
of their current feasibility 
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Table 5-1 enumerates and defines this initial set of modular proces- 
sing functions by major category. Figures 5-2 through 5-9 show the probabl 
alternative flow paths through these modular functions by major category. 
Again, these functional flow charts serve as an aid or checklist to the 
designer (an aid which is derived essentially independent of hardware con- 
siderations) whereby he may specify the functional capability of the system 
at a level of detail permitting a subsequent selection of equipment. 

A discussion of the functional categories follows: 

Preparation and Conversion - This group of processing functions provides 
for accepting imagery data in various media and formats. The input is 
assumed to arrive from three basic sources: 

o flight tapes and film from the onboard sensors representing 
the primary imagery of interest 

9 flight tapes representing ancillary data (attitude, ephemeris, 
voice annotation, etc ) from the onboard platform 

• supporting ancillary data which is historic or statistical 
in nature, or data that conies form other sensor sources 
which complements the primary data (e.g , ground truth 
data collected by in situ' instrumentation or low altitude 
aircraft underfl ights) 

Once this input data is reformatted, the next significant function is 
that of merging the imagery with ephemeris information (or other positional 
information, e.g., geodetic ground control points) to produce a complete 
data set. Following this processing, a minimum of six conversion options 
are open to obtain any desired image domain from any other (i.e., digital, 
video or film). This basic set of modular functions for conversion 
may be exercised within any of the major functional categories, at many 
intermediate processing steps. 
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Table 5-1 Modular Processing Functions 


I PREPARATION AND CONVERSION 

DEM0DE - Demodulating/Decompacting/Demul tiplexing 
REF0RM - Reformatting 

EPHEM - Geocentric coordinate assignment based on attitude 
and ephemeris calculations 

C0NVER - Image domain conversion 

A-T0-D - Convert video to byte sequence 

D-T0-A - Convert byte sequence to video 

SCANIM - Convert transparency to video 

RESCAN - Convert video to hard copy 

II. CORRECTION 

GRNC0N - Location and measurement of ground control points 

GE0C0R - Geometric location and frame correction based on 
ground control points 

RESEAU - Abstracting calibration fiducials 

CURVAT - Geometric correction in image projection due to 
earth curvature 

TERAIN - Geometric correction in image projection due to 
height profile of scene terrain 

ATM0S - Geometric correction due to refraction in 
atmosphere 

P0SITN - Geometric displacement correction due to errors 
in platform position 

ATITUD - Geometric correction due to error in sensor 
pointing 

RATE - Geometric correction for smear and distortion 
due to drift rates of platform 

SENGE0 - Geometric correction due to sensor electronics 

0PTGE0 - Geometric correction due to sensor optics 

TIMGE0 - Geometric correction due to recording system 

timing signal error 

ABS0RP - Radiometric correction due to atmospheric absorp- 
tion and background luminance 
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Modular Processing Functions (cont'd ) 


II. CORRECTION (Cont'd.) 

RADT0M - Radiometric correction due to signal noise 

SENRAD - Radiometric correction due to sensor detector/film 
response 

0PTRAD - Radiometric correction due to sensor optics 
aberrations 

RADC0N - Location and calibration of radiometric 
reference target on the ground 

RADC0R - Radiometric correction based on reference 
target calibration 


III. CORRELATION 

SELECT - Select image data sets for registration 

SCALIM - Change scale of image through reduction or 
enlargement 

MATCH - Select and measure match points 

REGTRN - Produce registration through translation of 
image data set 

REGR0T - Produce registration through rotation of image 
data set 

MERGE - Correlate and annotate ancillary data to image 
data sets 


IV. MANIPULATION 

Z00MIN - Select geographical area of interest within an 
image data set 

M0SAIC - Produce image mosaic by combination of data sets 

RES0L - Change effective spatial resolution by averaging 

between pixel rows and columns to reduce resolution 

GRID - Insertion of a reference grid into image data set 

SM00TH - Interpolation between neighboring pixels to 
minimize noise 

C0NTRA - Alter contrast by changing intensity values by 
a constant value or by mapping into another gray 
scale range 

THRESH - Produce an image data set by zeroing out all 
intensity levels below or above a specified 
threshold 
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Modular Processing Functions (cont'd.) 

IV. MANIPULATION (Cont'd.) 

NEGIM - Reverse intensity value range of data set 

SUBADD - Subtract or add two registered data sets 

TRANS F - Modify the intensity values in an image data 
set by an input functional transformation 

PATCH - Replacement of a missing image scan line by 
interpolation between adjoining lines 

TRANSL - Translation of an image data set with respect 
to a reference grid 

R0TATE - Rotation of an image data set through a specified 
angle 

INTERP - Location of picture points off integer scan rows 
and columns through two dimensional linear inter- 
polation 

SPAFRQ - Generation of forward and inverse transformations 
(i.e., Fourier and Hadamard) of an image data set 

FILTER - Multiply a given filter matrix by a transformed 
data set 

V. CLASSIFICATION AND RECOGNITION 

TRNSFM - Rotates observational data vectors using a 
principle axis transformation 

CLUSTR - Forms groups consisting of pixels with obser- 
vations which are close to each other in 
observation space 

FACT0R - Computes the mean vector, covariance matrix, 
eigenvalues, eigenvectors and the angle 
between each eigenvector and the mean 
vector of a cluster of data 

DTRMIN - Determines location of areas of known 
composition 

TRAINS - Computes signature of training samples 
(subset of FACTOR) 

MAXLIK - Classifies input observational vector using 
a maximum likelihood formulation 

MIXTUR - Decomposes data vectors along known basis vectors 

USEIG - Retrieves a priori signature 
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Modular Processing Functions (cont'd ) 

V. CLASSIFICATION AND RECOGNITION (Cont'd ) 

QUANTZ - Classifies pixels based upon the magnitude 

of a given component of the observation vector 

AS0CAT - Performs any necessary associations of clusters 
prior to output 

VI. MANNED INTERACTION 

DISPLA - Presentation of imagery or control data to a 
console situated operator 

0PTPRJ - Optical projection of image film transparencies 

C0MGEN - Computer driven display on monochromatic or 
color CRT 

M0NITR - The process of manned monitoring of a processing 
subsystem or image set data at intermediate pro- 
cessing points via a computer driven display or 
optical projection system 

SCREEN - Screening of image set data by selecting a 
reduced volume for subsequent processing 

C0NTRL - Manned intervention in the processing flow 

by designation of subsequent processing steps 

ANALYZ - Analysis and interpretation of data displays 
by man situated at computer driven displays 
or optical projection systems 


VII. OUTPUT PRODUCTS 

F0TMAP - Assembles necessary gridding and annotation 
information for preparation of photomap 

PRINTS - Produce photographic prints 

C0LC0M - Produce color composites 

SPCSLI - Performs spectral slicing 

TRANSP - Prodcues transparencies 

THEMEX - Produces thematic map 

C0NTUR - General purpose contouring 

0VRLAY - Produces photograph and map overlays 

STAPLT - Produces plots of statistical parameters 

HISGRM - Develops histograms 
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Modular Processing Functions (cont'd.) 


VII. OUTPUT PRODUCTS (Cont'd.) 

SCTDIG - Produces scatter diagrams 

SPCMES - Determine transmissivity of transparencies 

XYL0C - Automatically determines x-y location of points 
of interest 

HDDDTP - Produces high density tape 

CCTPR0 - Produces computer compatible tape 

SMLC0M - Produces special purpose data analysis program 
from available algorithms 

INVENT - Produces listings of automated inventories 
resulting from classification of imagery 

STSUM - Produces listings of statistical summaries 

PRDSUM - Produces summaries of production activities of 
ground data handling system 

VIII. DATA MANAGEMENT MODULAR FUNCTIONS 

AN0TAT - Annotation of ancillary complementing infor- 
mation to an image data set 

INDEX - Assignment of search code to image or 
ancillary data sets 

CATL0G - Entry of description of data sets and index 
code to master catalog 

ST0RE - Physical storage of source data sets in data 
management system 

SEARCH - Search or index code for data sets to be 
retrieved 

RETRIV - Physical retrieval or display of data sets 
of interest 

TRNACT - Bookkeeping of records of activity in 
storage/retrieval system 
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Figure 5-3. Correction Functional Flow 
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Figure 5-5 
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Figure 5-6. Classification and Recognition Functional Flow 














Figure 5-7 


t Products Functional Flow 


5-16 























1 



Manned Interaction Functional Flow 










5-18 



Figure 5-9. Data Management Functional Flow 











Correction - The set of functions under this category are intended to per- 
form either geometric or radiometric correction to the imagery. Two basic 
alternative paths are shown for each type of correction representation and 
modeling of the various error sources and applying incremental corrections 
based on these models, and a form of absolute empirical correction based on 
either surveyed and visible landmarks used as ground control points for 
geometric correction, or calibrated light sources on the ground (e.g,, laser 
"searchlights") for radiometric correction. 

Correlation - This category addresses the problem of registration of an 
image data set to a reference set. Typically, two images of the same 
ground scene but in different spectral bands would be brought into con- 
junction or registration. Additionally, this category includes the merging 
of ancillary data with the primary imagery (e.g., superimposition of statis- 
tical data on primary imagery). 

Manipulation - Functions performed in this category typically add no new 
information content to the image but instead- restore missing elements, 
manipulate intensity levels, enhance by filtering spatial frequency infor- 
mation or perform operations which assist m interpretation (e.g , super- 
impose a grid or construct large photomaps by mosaicing or piecing together 
adj'oining frames) 

Classification and Recognition - Included here are the various algorithms 
and decision rationale for pixel by pixel classification of multi spectral 
imagery data. Classification is based only on the spectral information 
content of the data and may proceed, in general, by: forming groups of 

pixels with observations which are "close" to each other in the observation 
space (i.e., clustering); or by classifying input observational vectors 
using a maximum likelihood formulation. Provision is also made for select- 
ing training samples, computing the sample reference signatures and 
using this to associate given clusters with the known objects in the ground 
scene. 
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Output Products - This category includes all functions necessary to produce 
the family of viable outputs at various intermediate stages of processing. 
The functions deal in general with the printing, plotting, film recording 
and photo processing of imagery data sets and rel event ancillary data. 

Manned Interaction - Included here are the manned or man-assisted functions 
of monitoring, screening, controlling and interpretation. These functions 
are assumed to be applied to either the primary imagery data (or ancillary 
data) or to the allocation and control of the processing subsystem resources 
Both on-line, interactive functions (e.g., CRT display driven by a computer) 
and off-line functions (e.g., man situated at a rear projection optical 
viewer) are included. 

Data Management - This category includes storage and retrieval of imagery 
data and derived statistics on subsystem performance. Functions within this 
category are intended primarily to accommodate relatively short term reten- 
tion of data for the purpose of correcting and calibrating subsequent 
processing of primary imagery. 

5.4 Equipment/Device Selection 

The definition of required modular processing functions was performed 
independently of devices or equipment types necessary to implement the 
functions. The end result of the synthesis effort, however, must be the 
selection and sizing of equipment to accommodate the processing functions 
The system designer must be capable of producing a tentative subsystem/ 
hardware schematic prior to assessment of overall system performance. 

To aid in the equipment selection process, and to help identify equip- 
ment alternatives, a general hardware concept is required. This concept is 
illustrated in Figure 5-10 "Master Equipment/Device Schematic." This con- 
cept is based on a high degree of centralized digital processing capability 
surrounded by various "work stations." The work stations shown in Figure 
5-10 are: 
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Input/Conversion Station 
Display and Control Station 
Image Specialist Station 

Optical Processing Station 

Electronic Analog Station 
Output Station 

Storage/Retrieval Station 


Characterized by reformatting, con- 
version and recording equipment 

Comprised typically of CRT display 
and optical projection equipment 

Equipment employed here is typically 
for image mensuration, viewing and 
auto or manual correlation 

Optical devices/lenses, light sources, 
filter fabrication and control, and 
film readers 

Typically a large scale, general 
purpose hybrid computer 

Film and tape recorders, scanners, 
photo processing lab, line printers 
and plotters 

Mass storage for digital data 
(e.g., drums, disks, tapes, etc ) 
and storage units for film reels 
and other hard copy 


The centralized digital processing resource is considered to take any 
of several forms including- a single large scale general purpose processor, 
parallel or multiprocessing systems, or multiple midi or mini computers. 
Supporting any of these architectures, the alternative of solid state spec- 
ial purpose modular processors is considered in two roles. 

• special purpose modules perform "front end" preprocessing 

e special purpose modules perform the bulk of all processing 

in multiple, parallel units under the control of a conven- 
tional software programmed computer 

The inherent work station organization in the "Master Schematic" is 
believed to be a viable and practical approach from both a facility layout 
consideration, as well as a concern for flexibility and growth potential. 
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5.5 Designer's Guide 

The following is a step-by-step scenario of the process through which 
a designer may start with user's data products requirements and proceed to 
synthesis of a trial processing system design. 

Step 1 - Designer must have an explicit description of the data 
products to be produced by the system These products 
will most probably be a reduced set of the product 
family illustrated in Figure 3-3. The specific 
attributes or characteristics of these products are 
described in Section 3.2. 

Step 2 - Designer defines a raw input data volume based on the 
acquisition capability of an existing or planned plat- 
form. This workload will define the volume, frequency 
and quality (i.e., spatial and spectral resolution) of 
the input imagery. 

Step 2 (Optional) - Designer estimates a raw input data volume 

required based on analysis of the required data products. 

An aid in providing this estimate is shown in Table 5-2. 

Step 3 - Designer selects the desired major categories, and 
modular functions within the categories, to be per- 
formed. Figure 5-11 "Data Products vs. Functional 
Categories"’ provides an aid in performing this 
selection. 

Step 4 - Designer determines the tentative flow of the selected 
modular functions based on the alternatives shown in 
Figures 5-2 through 5-9. 

Step 5 - Using the "Equipment/Modular Function Matrix," Figure 
5-12, and the "Master Equipment/Device Schematic," 

Figure 5-10, the designer specifies equipment types 
and interconnection. 

Step 6 - Designer ..estimates the size of individual devices and 
the tentative number of parallel units based on the 
overall input data volume (this estimate is simply 
a starting point for the subsequent design iteration 
based on performance simulation). 

Step 7 - For those functions to be implemented by digital 
logic, the designer specifies software or solid 
state specialized component execution. 
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Step 8 - Designer specifies a software top level program 
organization (as described in Section 6.4 "Com- 
puter System Simulation Program") and the central 
digital processing architecture. 

Step 9 - For the equipment types selected, the designer 
must specify the required performance and sizing 
parameters as required by the respective models 
(example shown m Section 6 5) 

The above steps, as illustrated m Figure 5-13, result in a degree 
of system definition that permits the simulation of throughput performance, 
as described in the following section. 
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Table 5-2 Input Data Volume Estimator 


DATA PARAMETERS 


RESOLUTION REQUIREMENTS FT (PI) 

ENCODING LEVEL (P2) 

INTERVAL BETWEEN OBSERVATIONS DAYS (P3) 

NUMBER OF SPECTRAL BANDS (P4) 

DESIRED SWATH WIDTH N Ml (P5) 

AREAL EXTENT N Ml 2 (P6) 


SIMULATION PARAMETERS 

FRAMES OF IMAGERY/ONE TIME TOTAL COVERAGE = P4 F° . R M ULTIBAND IMAGERY) . 

P5 

BITS/TOTAL ONE TIME COVERAGE = fc 080 ) P6 « H ~ ~ P2 

P1 

AVERAGE FRAMES/DAY = P4 FOR MULT1BAND IMAGERY) 

P5 x P3 

AVERAGE BITS/DAY = . < 6080 > 2 P6 X - P -1 * p2 

PI x P3 
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Figure 5-12. Equipment/Modular Function Matrix 





























/*/<? /(? //A7» / <y<?/^ 


'/£?/ </ 
'a / / <V / 1 


CORRELATION 





FXI 




SELECT 





nniiinun 




SCALIM 





■■DDK1DE3E]H^H 




MATCH 





MPgBMEHMM 




REGTRN 





mmmmmmwg&mmm 




REGR0T 









MERGE 









MANIPULATION 










Z00MIN 









MOSAIC 





HDDDm3E£3HS3M 




RES0L 





■DDDBIEQ^HESIIi 




GRID 





■BanKMEBEMRHH 




SMOOTH 





■EaDK3ElE3EMEI3Bi 




CONTRA 





■EH3DDES3E9BIE3H 




THRESH 









NEG1M 





■DBBDE9BBE3B 




SUBADD 





rn&mmmmmmmm 




TRANS F 





■DDDDE1PIPI 




PATCH 









TRANSL 





mwMWMWMWMmmmmm 




ROTATE 





■■3E1I1E1E3EME3H 




INTERP 





■DDDDESESBESH 




SPAFRQ 

1 








FILTER 

1 






. . 

, 


Equipment/Modular Function Matrix (cont'd.) 


















































EEPRODUdBILri'Y OP THE 
ORIGINAL PAGE IS POOP, 


i 

oo 

o 


' S’ /S'/ £'/&/§' 

/ £/////$/$'*> 




OUTPUT PRODUCTS 





















F0TMAP 













X 

X 


X 





PRINTS 













X 

X 


X 





C0LC0M 
















X 





SPCSLI 




AX 

AX 











X 

X 

X 



TRANSP 













X 

X 


X 





THEMEX 




AX 

AX 




X 

X 


X 




X 

X 




C0NTUR 

















X 




0VRLAY 
















X 

X 




STAPLT 

















X 

X 



HISGRM 

















X 

X 



SCTDIG 

















El 




SPCMES 




□ 

D 











n 

n 

m 



XYL0C 








■ 

D 







D 

□ 

n 



HDDDTP 







■ 

■ 

D 











19 

CCTPR0 









D 










D 


SMLC0M 









D 










B1 


INVENT 









D 









n 



STSUM 









D 









D 



PRDSUM 









D 









D 




Equipment Modular Function Matrix (cont’d.) 












USER MANAGEMENT REQUIREMENTS 



REQUIRED DATA PRODUCTS 


SET OF POSSIBLE 
REQUIRED MODULAR 
FUNCTIONS 




PRECISE STATEMENT OF OBSERVATION 
REQUIREMENTS 

• RESOLUTION 

• POINTING KNOWLEDGE 

• NUMBER O F SPECTRAL BANDS 

• FREQUENCY 

• SYNOPTICISM 

• SPECTRAL FIDELITY 

• GEOMETRIC FIDELITY 

• AREAL REQUIREMENTS COVERAGE 




SELECTION OF CANDIDATE 

• SENSING PLATFORM 

• SENSOR 

» MISSIONS 





ASSESSMENTS OF 
DATA LOAD 


ANALYSIS OF BASIC CAPABILITIES 
VERSUS OBSERVATION REQUIREMENTS 




SELECTION OF 
MODULAR 

\ 

SELECTION OF 
EQUIPMENT 

> 

FUNCTIONS 

/ 


Figure 5-13. System Designer's Approach 
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6 0 SYSTEM PERFORMANCE SIMULATION 


This section details a simulation concept developed to help design 
and/or evaluate a data processing facility It describes the need for an 
evaluation tool, what these tools (computer programs) are, how they simu- 
late the system, how to prepare software and/or hardware models for them, 
and finally what outputs are received from the computer runs. 

6.1 Simulation Objectives 

As shown in Section 5.0 a total ground data processing facility for 
earth resources data would normally consist of a variety of equipment such 
as 

t viewers 
i image digitizers 
§ densi tometers 
0 tape recorders/playbacks 
0 digital computers 
0 printers 
0 plotters 
0 film developers 
0 CRT's 

and many other devices depending upon the type of data received and the 
processing to be performed. In addition to all of the equipment required, 
there would be steps in the reduction where analysts would greatly influence 
the flow of data. Some man interface functions include. 

0 operation of the equipment 

0 determining what data is to be processed 

0 view data from CRT's and introduce instructions into 
the computer for special operations 

a transport data from one station to another 
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The effective flow of data and utilization of equipment therefore 
requires a data system which is described by many different variables such 
as- 

• device speeds 

• time required for a man to make a logical decision 

• software routines to be used for data correction 

9 computer cycle time 

o number of pieces of similar equipment 

as well as numerous other detailed items which all introduce delays into the 
total system throughput. 

Because of all of these variables and complexities, it is not intui- 
tively obvious what ground station configuration will most efficiently 
process the data, maximize the use of equipment and minimize the cost of the 
total facility 

In order to help the ground station designer answer these questions 
the "Equipment Simulation Program" (ESP) was developed. This program, along 
with its support program, "The Computer Simulation Program (C0MPSIM) helps 
the system designer determine what his system throughput will be. For each 
point design simulation he runs he can maintain subsystem cost records to 
relate to the equipment utilization results obtained by the program. After 
simulating a number of different system configurations he can then determine 
the most cost-effective system to perform his job. 

6.2 Simulation Approach 

The system simulation approach is based on the assumption that a data 
system should be thoroughly evaluated before purchase or lease of hardware 
The ideal situation would be to actually run the system on benchmark sets 
of data. However, since the total system is probably unique and the soft- 
ware is probably not yet developed, this approach is generally impossible. 
The next best approach is to model the components of the system and run 
computer simulations of the equipment processing given work loads. The 
results can then be analyzed and adjustments in the equipment types, number 
of configurations can be made 
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The simulation approach to detailed design of ground data facility 
is shown in Figure 6-1. Each circle represents a step in the selection 
procedure. First the data processing requirements are defined to the sys- 
tem designer. Typically the requirements consist of the amount of data to 
be processed and the end result products expected to be produced by the sys- 
tem Next, the designer must define the functional requirements This 
step consists of defining a flow of data through devices and computers and 
defining the processing required at each step. He must also define the 
computer programs required and what function each performs. 

Now he must take the functional requirements and determine the equip- 
ment best suited for performing those functions. The designer may be some 
what constrained by a requirement to use some existing equipment, or he 
may be totally free to specify all equipment The data facility design 
must be such that the throughput requirements can be met, bottlenecks do 
not exist, and cost is minimized. Because of the trade-offs among these 
variables it becomes very difficult to synthesize one system configuration 
and be confident that that system is optimal. Therefore, it becomes desir- 
able to evaluate the system on some basis other than hand calcualtions of 
its performance. Trying to follow the flow of data throug h man y different 
devices and computer programs quickly becomes an overwhelming task. The 
need for a computer program to simulate the data flow and maintain key 
statistics becomes very obvious. 

ESP and its support program C0MPSIM were designed for this task. ESP 
will simulate a flow of data through a set of various devices and maintain 
key statistics such as. percent utilization, maximum wait time for an entity 
of data, maximum length of the wait queue, etc. These are the statistics 
that locate bottlenecks and determine the utilization performance of the 
equipment. 
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The C0MPSIM program simulates the detailed operation of a digital 
computer and maintains similar statistics regarding program, channel, device, 
and processor utilization 

The system performance simulation programs use the TRW developed SALSIM 
discrete event simulation subroutine. This set of subroutines introduces a sim- 
ulation capability to FORTRAN. They also eliminate the need for a special 
language and provide for unlimited expansion of capabilities by addition of 
new subroutines, called functional operators, as the requirement arises. 

SALSIM also provides for a dynamic storage where storage is released when 
not further needed, allowing for use later in the simulation run. Expansion 
of the capabilities of simulation languages is typically difficult, but 
addition of extra subroutines to SALSIM is made relatively easy through 
the functional operators. 

Using a functional operator found m SALSIM, a programmer writes 
F0RTRAN models of the equipment or process to be simulated These models 
provide for a flow of activities and simulate all time delays encountered 
Important statistics concerning the processing is maintained and printed 
at the end of a simulation run. These statistics show the throughput, 
percent utilization, unit queues, and other data vital to the analysis of 
a system's capability to process a given workload. 

SALSIM is currently operational on the NASA/MSC 360/75, under RTOS 
and is used in the simulation programs described m the following two 
sections 

6.3 The Equipment Simulation Program (ESP) 

The Equipment Simulation Program was designed to simulate data pro- 
cessing systems which contain analog, digital and man-in-the-loop components. 

The program uses SALSIM to simulate the movement of data through the total 
system At the completion of a run, statistics provide for the evaluation 
of all pieces of equipment, or man intervention steps, in the complete data 
processing station. The program provides for input of photographic, analog 
or digital data, or a combination of any two or three and simulates the 
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processing of the data through devices selected by the user. Each device 
has a model (or subroutine) which defines the functions of that device. 

A set of parameter cards is provided to input key values relating to the 
computation of the device throughput. 

6.4 The Computer Systems Simulation Program (C0MPSIM) 

When the system designer addresses the problem of evaluating digital 
computers, the interactions of events become so complicated that the com- 
puter's capability and execution time to perform its given task are virtually 

V 

impossible to determine manually. This is especially true when large scale, 
multiprocessor, multi programmable computers with complicated executive sys- 
tems and multiple input/output channels, are under evaluation. To help the 
system designer evaluate the computers in the system, program C0MPSIM was 
developed. It provides detail software timing values for the computer 
functions in the ESP simulation. 

There are three major components to any computer* 

• Executive - the executive system is the master of the 
computer operation. It selects programs to be executed, 
answers interrupts from devices and routes input and 
output data to and from devices. It has total control 
over the internal operation of the machine, based upon 
the parameters provided it by the system or computer 
designer. These parameters consist of priority of 
programs, routing of input/output messages and 
interrupts . 

• Programs - One of the primary purposes of C0MPSIM is 
to determine the total elapsed time required by a 
program to run to completion. Each program must be 
modeled, either by parameter cards or subroutine. 

A flow chart of the programs operation is used to 
determine the logical steps performed by the program, 
read, compute, write, branch based upon a probability 
of a computed value being within a given range, etc. 

• Input/Output - Output devices may be computer storage 
devices such as disks or tapes or may be the next step 
in the data processing, such as CRT's or thematic plot- 
ters. Input devices also could be logical extensions 
of the computer or input channels from exterior devices 
such as digitizers. Exterior devices usually generate 
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interrupts to signal the computer that data is being 
sent through the channel. The executive must answer 
that interrupt and usually delays the executing pro- 
gram and schedules an input processor routine. One 
of the jabs that C0MPSIM performs is to determine how 
interrupts delay the execution of application 
programs thereby determining the actual elapsed time 
to completion of program. 

These three components, along with the CPU('s) which actually perform 
the computation (the resource for which almost everything is competing) are 
simulated by C0MPSIM on a step by step basis Figure 6-2 shows the major 
computer components and their connection. The external system shown repres- 
ents input devices which generate random interrupts (such as an interrupt 
from an operator console or CRT). 

6.5 Equipment Models and Modular Functions 

A sample application of the modular functions related to an equipment 
model is shown in Figures 6-3 and 6-4. The desired data product is a very 
simple photomap with limited thematic identification. The image data is 
available in the form of video signal on video tape. The modular functions 
necessary in this example application are: 

• convert from video (analog) to digital signal (A-T0-D) 

• reference the data to an ephemeris (EPHEM) 

■ provide limited geometric correction of the data caused 

by the sensor optics (OPTGE0), the sensor circuitry (SENGE0), 
and the curvature of the earth (CURVAT) 

• provide limited radiometric corrections due to the sensor 
circuitry (SENRAD) 

• examination of the data by an operator (DISPLAY) 

• manipulation for enhancement of the data through combination 
of data channels (SUBADD) and visual emphasis of certain data 
characteristics via thresholding (THRESH), i.e., ascribing a 
certain color to all data m a channel (s) above or below a 
certain value level 

• once the data has been combined or displayed in a suitable 
fashion, photo prints thereof can be made (PRINTS) 
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Figure 6-2. C0MPSIM Program Organization 

















Figure 6-3. Functional Flow of Sample Subsystem 
















6-10 






FILM 

PRINTS 


Figure 6-4 


Sample Subsystem Schematic 







The above set of modular functions might be typical for an applicati 
wherein fine resolution, close registration, and absolute geographic refer 
ence were unnecessary, e.g., theme extraction for a coastal region 
depicting large areas of marsh, sand and water where the observer may only 
be interested in the gross areal extent. 

Selection of the equipment complement type necessary for modular 
function implementation can be made from Table 5-12, "Equipment/Modular 
Functions Matrix" and Figure 5-10, "The Master Equipment Device Schematic. 
Applying experience and judgement, the minimum equipment complement con- 
sists of 

• a video tape playback (or recorder) and control unit to 
respond to computer control 

• an analog to digital conversion unit to make the data 
compatible with the digital computer input 

• a digital computer is required to provide for reading 
the ephemeris, geometric, and radiometric data from 
tape inputs. The computer subsequently performs the 
necessary calculations to effect the proper correction 
control signals to the film writer. These signals 
include the incremental x and y deflection values 
plus the z axis modulation values to be applied to 
each pixel as it is written 

• a CRT and operator console equipment are required so 
that the operator may view the data and cause the 
channels to be manipulated to depict the enhancement 
or thematic content desired by the operator 

e the film recorder equipment may be of the EBR (Electron 
Beam Recorder) type or the CRT type so long as the 
intensity of the beam and the deflection may be incre- 
mentally influenced by the digital computer output 
signals to effect geometric and radiometric corrections 
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The next step in evaluation of the sample application is identification 
of the equipment device parameters so that sizing and system operation may 
be analyzed and evaluated via the simulation tools available. Typical model 
parameters for the device types are shown below 

« Tape Drive 

Search Time 
Read Rate 
Start 

• Display, CRT 

Turn On and Warm-up Time 
Access Time 

Scan Line Acceptance Rate 

Operator Observation Time, Kean, Spread 

Probability of Operator Request for Manipulation Routines; 

Subadd 

Threshold 

Display Command Delay Times 


§ Computer 

Number of Processors 
Core Memory Size 
Cycle Time 
Executive Overhead 
Parameters for each Program ; 

Routine Process Time 
Other Devices Accessed 
Size of Record Accessed or Released 
Storage Seized or Released (New or Old) 
List of Programs; 

Digitizer Input and Storage Routine 
Ephemeris Read and Correction 
Optical Geometric Correction 
Sensor Geometric Correction 
Earth Curvature Correction 
Sensor Radiometric Correction 
Display Routine 

Image Channel Manipulation Routines 
(Add, Subtract, and Thresholding) 
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• Video Tape 

Start Time 

Search Time, Mean, Spread 
Number of Auxiliary Channels 
Time Internal/Lme Scan 
Scan Line Interval 
Scan Lines/Image 
Stop Time 

• A to D 

Stage Delay 
Sync Pulse Delay Times 
Bits/Scan Line 
Scan Line Interval 

« Disk Storage 

Storage Capacity 
Storage Used/Rel eased 
Access Time 
Line Rate 

Once the above device parameters have been determined, it is possible 
to employ the simulation tools to determine system performance in terms of 
throughput, time delays and volume. Quantitative information will be 
desired relating to 

® bulk memory size and speed 

• core memory size and speed 

• display and other peripheral operation while processing 
« word sizes, interface breadths and transfer rates 

• primary and secondary data structures 
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As the data and parameters evolve for the proposed system device 
implementation, three options are available: 

9 if the implementation is simple enough, there is no 
need for simulation since adequate calculations may 
be performed manually 

9 if the implementation is complex, then the simulation 
offers a good solution 

e the system implementation program may be such as to 

require both manual and simulation methods of evaluation 

In the above sample system, some example parameters for the system 
data source might be as follows 

Video Tape 

Start up time 
Search time 
Aux channel 
Bandwidth 
Scan line data 
interval 

Scan line non-data 
interval 

Scan lines/image 
Frame data interval 
Frame non-data 
interval 

Total frame time 


50 sec. 

0 sec. , 7.5 min. 

2, ( timing, 1 audio) 

3.2 MHz 

720 usee 

80 usee 

4125 lines 

3.3 seconds 

0.2 seconds 
3.5 seconds 


In the above example, probably the most significant parameter of the data 
source is the fact that a frame of data can be input in about 3.5 seconds. 
For an ERTS type image the equivalent is approximately 16 million pixels 
or about 100 megabits of information to be handled and processed. If data 
can be made available at that rate, the question arises, is it possible to 
process and extract the desired results and output at the same rate? Film 
writing output devices can be found which will write that size image with 
time ranging from about 12 minutes down to the required 3.5 seconds. This 
then permits a tradeoff in throughput rate vs. cost. 
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6.6 C0MPSIM Software Models 


C0MPSIM provides two methods for implementing software models. In 
the first method, for executives and other complex programs, the model can 
be written in F0RTRAN. A set of subroutines, called software operators, 
is provided to perform the necessary simulation functions. The second 
method, for less detailed models, is to construct the model entirely from 
software operators on special input cards. The resulting program model is 
executed interpret! vely. A given simulation may contain both simple and 
complex program models, in any order, with no restrictions on referencing 
from one type to another. 

6.6.1 Complex Program Models 

Any software model that requires calculations to be performed with, 
or logical decisions to be based upon, system attributes from the simulation 
data base must be written in F0RTRAN. All such attributes are stored in 
the SALSIM dynamic array Any C0MPSIM software operators, most SALSIM 
operators, and all FORTRAN statements are legal in constructing a complex 
program model . 

A set of subroutines, called software operators, is used to simulate 
the effect of the executing software model on the simulated hardware. 

These operators are: 

JUMP (PGM) Jump to program specified by PGM. PGM may 

be either program ID or program number 

JUMPR (IRET, PGM) Set the return address (location of statement 

number IRET) in the event notice before jump 
to PGM 

RETN Go to return address previously stored in event 

noti ce 

JUMPX (IDN) Destroy current event notice and resume processing 

with IDN. Used for restarting delayed tasks by a 
scheduler routine. 
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PR0CES 

{ IRET, INST, WGT) 


ENABLE 

DISABL 

TRIGGR 

(LVL, PGM, TASK) 


TIMER 

(NTMR, LVL, 
DELT, PGM) 


WAIT 

(IRET, IDSCH, 
IDQ, I0WN) 


IDLE 

ENDINT (IDSCH) 


READ 

(DEV, NCHAR, 
WTCNT) 


Process for time equal to number of instructions 
(INST) x weighting factor (WGT, cycles per instruc- 
tion) x CPU cycle time. If WGT = 0, a default 
value for each CPU is used. If INST = 0, WGT 
is assumed to be actual processing time in ys. 
After process, next statement is IRET. 

Allow interrupts on current CPU. 

Lockout interrupts on current CPU 

Cause an interrupt on current CPU with a priority 
of 1 OOOOxLVL+pri or i ty of PGM (0-999). If TASK 
= 0, a new event notice will be created. If TASK 
= current event notice, TRIGGER operates as com- 
bination TRIGGR and ENDINT This is useful when 
information contained in the current event notice 
must be passed on to another program at a differ- 
ent interrupt level. 

Cause a delayed interrupt on current CPU in DELT 
sec with priority = 1 OOOOxLVL+pri or ity of PGM. 

If NTMR = 0, a new event notice will be created 
for each call to TIMER. If NTMR f 0, and is 
less than the number of timers defined for the 
current CPU, a special event notice will be 
used, and its time of occurrence changed by 
each call to TIMER 

Wait for I/O. Task is delayed until all messages 
specifying task delay have completed transmission. 
If IDSCH, IDQ, and I0WN are specified, the cur- 
rent event notice is placed in a special waiting 
queue and a new task starts with IDSCH. After 
all messages have completed, the event notice is 
moved to the queue specified by IDQ and I0WN where 
it is available for rescheduling If IDSCH = 0, 
the event notice does a large PR0CES until all 
I/O has completed. 

Idle current CPU if no outstanding interrupts. 

Ends interrupt processing. If no returns are 
present in event notice, control is passed to 
IDSCH, or if IDSCH = 0, CPU is idled. 

Read a record from device DEV of length NCHAR. 

If processing must stop until completion of read 
WTCNT = 1, otherwise WTCNT = 0 
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Same as READ 


WRITE 

(DEV, NCHAR, 

WTCNT) 

S 10 (DEV) Start an input or output operation on device 

DEV, Not necessary before a READ or WRITE. 

CHACT (CHANN0) Activate data channel CHANN0 

CHDACT (HANN0) Deactivate data channel CHANN0 

6.6.2 Simple Program Models 

Simple program models are input on parameter cards according to the 
format described under Software Operator Cards in Section 6.7. The follow- 
ing operators are available for use: 


Operator 

Parameters 


PROCESS 

TIME 

(ms) 


WAIT 

PGM 



JUMPR 

PGM, 

ARGS 


RETN 

None 



JUMP 

PGM, 

ARGS 


ENDINT 

PGM 



ENABLE 

None 



DISABLE 

None 



IDLE 

None 



TRIGGR 

PGM 



TIMER 

PGM 



READ 

DEV, 

NCHAR, 

WTCNT 

WRITE 

DEV, 

NCHAR, 

WTCNT 


The following operators are unique only to simple software operators 


Operator 

Parameters 

Description 

BRANCH 

INST, PROB 

Instruction number, 
probability of looping 

CALL 

ROUTINE, 

ARGS 

Routine name, arguments 

LOOP 

INS, CNT 

Instruction number, 
number of loops to be 
performed 
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6 7 I nput Data Structure 

6.7 1 Equipment Simulation Program 

ESP parameters consist of three types of cards, all in a fixed field 
format. They define the type of data, flow of data through equipment and 
equipment parameters. 

Data Identification Cards - These three cards identify data as photographs, 
analog recorded, or digitally recorded. There must be one card for each 
type, even if there is no data of a given test type. The format is given 
in the table below* 


COL 

CONTENTS 

10 

I = image data (i.e., photograph) 
A = analog recorded data 
D = digitally recorded data 

15-20 

Total number of frames of this type of data to 
be processed 

21-30 

Time at which this data is to be introduced 
into the simulation 

31-40 

Number of data points per frame (if digital) 

48-50 

Number for first piece of equipment to process 
this data. (See data flow cards.) 

57-60 

The total number of pieces of equipment used 
in first processing step 


Data Identification Cards 


Data Flow Cards - These cards give the simulation the order in which frames 
of data flow through the various pieces of equipment. The format is given 
in the following table. 
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COL 


CONTENTS 


1-5 Card number All data flow cards are numbered 

1-N. Each card represents an equipment station 
or a man-assisted function in the total processing 
system. 

10 C = more than one previous station 

13-16 The name of the device used by this step of the 

data reduction 


26-30 Next step card number. Card number of the next 

equipment station 


30-35 

35-40 

40-45 


If there is more than one next station, these 
columns give the other stations card numbers 


45-48 Normally blank. If this card represents the 

last step of the data reduction, this field 
contains an END$ or FINI 


Data Flow Cards 


Equipment Parameter Cards - These cards contain the required parameters for 
each device For example, the digitizing rate of an A-D converter, the 
probability of an on-line analyst rejecting a frame due to cloud cover, etc. 
The format is specified below. 

COL CONTENTS 


3-6 


17-20 

31-40 

41-50 

51-60 

61-70 


The name of this piece of equipment (same as col. 
13-16 of the data flow cards). The last card 
contains ENDjzi in this field and all other fields 
are blank 

Total number of pieces of equipment of this type 

Parameters pertaining to operation of this piece 
of equipment. Parameters continue on the next 
card(s) in these fields (with col. 1-30 blank) 
until all required parameters are input 


Equipment Parameter Cards 
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The parameters to be used in these cards are defined for all pieces 
of equipment as the model for that equipment is developed 

6 7 2 C0MPSIM 

There are four categories of C0MPSIM input cards: group header cards, 

standard attribute cards, user attribute cards, and software operator cards 
(for simple program models which do not require F0RTRAN for logic and com- 
putation). An input group consists of a group header card, a standard 
attribute card for each entity of the group, an end of data card (*E0D), 
and, optionally, a user attribute card for each entity. The order of input 
groups is not restricted nor is the order of standard attribute cards with- 
in the group. However, if user attributes are specified, the corresponding 
user attribute card must follow each standard attribute card. Any program 
models (using software operator cards) must immediately follow the PR0GRAMS 
input group. If there are no simple program models, the PROGRAMS input 
group must be followed by two end of data cards. Also, the last input group 
must be followed by an additional end of data card. 

Many input cards contain hollerith data as well as an input string of 
numbers. Therefore, the following notation will be used in all tables in 
this section. 

« Location of data on card (L0C). 

ci-j means card columns i through j 
Pn means parameter number n of the input string 
Pl(i) means parameter 1 of the input string which 
starts in column i 

9 Type of data (TYPE): 

A means alphanumeric 
I means integer (no decimal point) 

R means real (must have decimal point) 

s Attribute names (ATTR NAME), where listed, are internal data 
names. If an attribute name is not given, the parameter is 
used only during initialization 

All parameter input fields (denoted by Pn in L0C columns), even the 
final field in the string, must be terminated by a comma. 
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Group Header Cards - There are ten input groups in C0MPSIM. PR0GRAMS, 
FILES, CHANNELS, MULTIPLEXERS*, C0NTR0LLERS, DISCS, DRUMS, TAPES, SEQ 
DEVICES, AND PR0CESS0RS. Each input group must begin with the appropriate 
Group Header card (see following tables). Only the first four four letters 
of the group name are required, the rest are optional. 

Standard Attribute Cards - Each input group must contain a standard 
attribute card for each entity referenced in the simulation. A reference 
can come from a software model (a JUMP(N) operator requires that program 
N be defined), or from another input group (if file X specifies residence 
on drum Y, drum Y must be defined). The header card specifies the maximum 
number of entities in the system (for that group), and core is allocated 
for this number Entity numbering is from 1 to the maximum and unreferenced 
numbers do not have to be defined. Attribute cards do not have to be in 
sequence by entity number, and a second card with the same entity number 
will override the first description. 

User Attribute Cards - If the group header card for an input group 
specifies user attributes (1 £ P2 £ 10), each standard attribute card must 
be followed by a user attribute card. All user attribute cards have the 
same format, a string of up to ten parameters starting in column one. The 
meaning of the parameters must be determined by the user. Each input group 
has an associated C0MM0N block which contains all of the attribute pointers 
(to locations within the SALSIM dynamic array) for that group. Pointers 
to user attributes will be stored in a size 10 array whose name ends in 
USER. For example, the pointer to the second user attributes of PR0 GRAMS 
would be in PUSER(2) . 

Software Operator Cards - Simple program models can be defined by 
means of software operator cards. The operators that can be used in this 
fashion, and their associated parameters, are described in Section 6.7. 


* Not in current version of C0MPSIM 
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GR0UP 

NAME 


L0C 


TYPE 


ATTR 

NAME 


DESCRIPTION 


PROGRAMS 

Cl -4 
PI (13) 
P2 
P3 

P4 

A 

I 

i 

I 

I 

NPGM 

’PR0G' 

Number of programs in system 
Number of user parameters 
Maximum number of software opera- 
tor cards m a program model 
Maximum storage requirement 
for a simple program model 

FILES 

Cl -4 

A 


'FILE' 


PI (C13) 

I 

NFILES 

Number of files in system 


P2 

I 


Number of user attributes 

CHANNELS 

Cl -4 

A 


1 CHAN 1 


PI (13) 

I 

NCHAN 

Number of files in system 


P2 

I 


Number of user attributes 

CONTROLLERS 

Cl -4 

A 


' C0NT ' 


PI (13) 

I 

NC0NT 

Number of device controllers 


P2 

I 


Number of user attributes 

DISCS 

Cl— 4 

A 


'DISC' 


PI (13) 

I 

NDISC 

Number of discs in system 


P2 

I 


Number of user attributes 

DRUMS 

Cl -4 

A 


‘ DRUM 1 


PI (13) 

I 

NDRUM 

Number of drums in system 


P2 

I 


Number of user attributes 

TAPES 

Cl -4 

A 


■TAPE 1 


PI (13) 

I 

NTAPE 

Number of tape drives 


P2 

I 


Number of user attributes 

SEQ 

Cl -4 

A 


■SEQb' 

DEVICES 




Number of sequential devices 





Number of user attributes 


Group Header Cards 
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GROUP 

NAME 

L0C 

TYPE 

ATTR 

NAME 

DESCRIPTION 

PROGRAMS 

Cl -4 

A 

PGM 

'First four 1 char of pgm name 


C5-8 
PI (10) 

A 

I 

PGM2 

Last four char of pgm name 
Program number 


P2 

I 

PGMPRI 

Program priority 


P3 

I 

PTYPE 

Program type (1 = exec, 2 = app) 

FILES 

PUD 

I 


File number 


P2 

I 

FTYPE 

File type* 1 = random 

2 = sequential 


P3 

I 

FADDR 

Starting address of file 


P4 

I 

FSIZE 

File size in granules 


P5 

I 

FREC 

Record size in characters 
(sequential) or smallest acces- 
sed group of char, (random) 


P6 

I 

FDEV 

Device (type and number) where 
file resides 


P7 

I 

FGRAN 

Granule or block size in 
characters 

CHANNELS 

PUD 

I 


Channel number 


P2 

I 

CHTYP 

3 digit channel description, a b ■ 
a = 0, interrupts do not deacti- 
vate chan 

= 1, interrupt deactivates 
until CHACT 

= 2, chan deactivated until int 
recognized by CPU 
b = 0, integral channel 
= 1, direct memory access 
c = 1, selector type channel 
= 2, RR multiplexor 
= 3, priority mux .(1 me 1 
highest priority) 


P3 

I 

CHCPU 

CPU to which channel is connected 


P4 

R 

CHRATE 

Channel rate (char/sec) 


P5 

R 

CHSEL 

Line selection time (ms) 


P6 

I 

CHIL 

Interrupt level 


P7 

R 

CHINT 

Channel interference for 1 
transfer 


P8 

I 

CHNL 

Number of lines 


P9 

I 

CHNC 

Number of char transferred in 
parallel 


PI 0 

I 

CHIPGM 

Interrupt answering pgm #1 


Standard Attribute Cards 
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C0NTR0LLERS 

PIO) 

I 


Device controller number 


P2 

I 

DCLINK 

Channel (2 digits) and line # 
(2 digits) of device cont 


P3 

R 

DCBUFR 

Buffer rate if controller is 
buffered 


P4 

I 

DCNL 

Number of lines for devices 

DISCS 

PUD 

I 


Disc number 


P2 

I 

DILINK 

Link type (1 digit; 1 = channel 





2 = device controller, 3 = mux.) 
number (2 digit), and line 
number (2 digit) . 





(line 7 of device controller 3 
= 20307) 


P3 

R 

DIACS 

Access time in sec. If 
DIACS 0., a random access time, 

0 ^cs W Wl11 be used 





If DIACS = 0, the access time 
will be computed using specified 
address and current angular 
position 


P4 

R 

DIR0T 

Period of rotation in sec. 


P5 

R 


Interleave factor 


P6 

I 

DITKSZ 

Track size (char) 


P7 

I 

DISEEK 

Seek function number; must cor- 
respond to a user supplied func- 
tion, SEEKFn, where 1 n 9. 


P8 

R 

DIAVSK 

Average seek time in sec if 
no seek function is supplied 

DRUMS 

PIO) 

I 


Drum number 


P2 

I 

DRUNK 

See DILINK 


P3 

R 

DRACS 

See DIACS 


P4 

R 

DRR0T 

See DIR0T 


P5 

I 


Interleave factor 


P6 

I 

DRTKSZ 

See DITKSZ 

TAPES 

PIO) 

I 


Tape number 


P2 

I 

TPLINK 

See DILINK 


P3 

R 

TPLAT 

Start-up time (sec) 


P4 

R 

TPXFER 

Data transfer rate (char/sec) 


Standard Attribute Cards (Cont'd.) 
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SEQ 

DEVICES 

PUD 

P2 

P3 

P4 

P5 

I 

I 

R 

R 

R 

SQLAT 

SQLAT 

SQIRTE 

SQ0RTE 

Sequential device number 
See DILINK 
Device latency (sec) 
Input rate (char/sec) 
Output rate (char/sec) 

PR0CESS0RS 

PUD 

I 


CPU number 


P2 

R 

PCYTM 

Cycle time (micro-sec) 


P3 

I 

PCC 

Word size (char) 


P4 

R 

PRTM 

Minimum channel interference 
to be considered 


P5 

R 

IWGT 

Average number of cycles per 
instruction 


P6 

I 

NTMRS 

Number of software accessible 
timers 


Standard Attribute Cards (Cont'd.) 
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FORMAT 

LOC 

TYPE 

DESCRIPTION 

1 

Cl -5 

I 

Statement number 

(Do not use on PROGRAM or END 

card) 


C7-14 

A 

Operator name 


PI (16) 

I or R 

First parameter 


P2-Pn 

I or R 

Remaining parameters (up to 20) 

2 

Cl -5 

I 

Statement number 


C7-14 

A 

Operator name 


Cl 6-23 

A 

First parameter 


P2 ( 25 ) 
-Pn 

I or R 

Remaining parameters 


Software Operator Card Formats 


Format 1 is valid for all software operator cards. Format 2 is valid 
for operators which reference another program model. In this case, the 
first parameter may be either the program number (format 1) or the program 
name (format 2). 
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6.8 Output Information 

6.8 1 Equipment Simulation Program 

The general output of the Equipment Simulation Program consists of 
two lines of statistics for each type of equipment and each device 
as specified by the input parameter cards. Some models will print add- 
itional statistics relating to that device. The first line gives the 
equipment utilization for each equipment type. It contains 

• Percent Utilization - the percent of the total simulation 
time during which the device is being used by a frame of 
data 

• Total number of frames of data using the device 

• The average time used by each frame 

• A number identifying the user at the end of the run, if any 

® The total number of interrupts which occurred, if the device 
is interruptable 

The second line gives statistics regarding the wait queues at each 
device: 

« The total number of frames which had to wait to be processed 

• The total number of frames waiting to be processed at the 

end of the run 

• The maximum number of frames waiting in the queue 

• The average contents of the wait queue 

« The average time per frame spent in the wait queue 

The last two entries are standard SALSIM printouts and do not pertain 

to ESP. Table 6-1 shows an ESP run on a sample system and all of the 

output described above. 
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Table 6-1. ESP Output 
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682 C0MPSIM 


Three types of output: are available from C0MPSIM Two of these, the 
operator trace and summary statistics, are built-in to the simulation. The 
third type, often the most important, is user generated output which is 
tailored to the specific problem under study. An example of each type of 
output is included in this section. 

Operator Trace 

The operator trace is designed to provide a detailed history of the 
software execution Selected operators (see table below) cause a line of 
output to be printed each time the operator is used. Operators are selected 
by setting bits in the program variable ITRACE. In addition to the software 
operators, a trace line can be obtained whenever a CPU interrupt occurs 
(CPUINT) and when a higher priority task takes over the CPU (DELTSK and 
NEWTSK). A trace line consists of the current simulation time, the operator 
name, the current task pointer, current CPU, the first four characters of 
the current program name, and the previous (calling) program name, the time 
the current program began execution, the interrupt priority, the remaining 
process time, the 1/0 wait count, and information on the associated message. 
The trace is useful for timing studies and also to insure that the software 
models are executing as expected An example of trace output is shown in 
Table 6-2. 


TRACE SELECTION VALUES 


Bit 

No. 

Integer 

Value 

Cumulative 
Val ue 

Operators for Which Trace Activated 

0 

1 

1 

CPUINT, NEWTSK, DELTSK 

1 

2 

3 

JUMP, JUMPR, JUMPX, REIN, IDLE, ENDINT 

2 

4 

7 

TRIGGER, TIMER 

3 

8 

15 

ENABLE, DISABL 

4 

16 

31 

PR0CES, WAIT 

5 

32 

63 

SI0, READ, WRITE 

6 

64 

127 

CHACT, CHDACT 


Trace Operators 
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Table 6-2. C0MPSIM Trace Output 


co 

i 

oo 

o 


1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

i 

1 

1 

1 

1 

1 

1 


TIME 

ePERATOR 

TASK 

CPU 

CPGM 

RETN 

MARK TIME 

INTPRI 

RT IMF 

HTCNT 

MSG 

OP I G 

ofs r 

CHAO 

PR0T 

.908319 

PROCES 

198 

1 

SUPE 


1.908070 

1POOOO 

.OOOOor 

0 

366 

1 

0 

1 

0 

.910565 

TRICGR 

198 

1 

SUPE 


1 . 908070 

inoooc 

• OOOOC'' 

c 

366 

1 

0 

1 

0 

.910565 

ENDINT 

198 

1 

SUPE 


1 . 908070 

lnoooo 

.oooo* r 

c 

366 

1 

0 

1 

0 

.910565 

CPUINT 

416 

1 

INTP 


1.910569 

140801 

•0000< " 

0 

0 

0 

0 

0 

0 

.910565 

NEWTSK 

416 

1 

INTP 


1.910569 

140201 

. OOOOOo 

0 

0 

0 

0 

0 

0 

.910565 

JLMFR 

416 

1 

INTP 


1.910569 

140801 

. OOOOl ( 

0 

0 

0 

0 

0 

0 

.910565 

PROCES 

416 

1 

RADI 

INTP 

1.910569 

140801 

. 0000O0 

1 

0 

0 

0 

0 

0 

.910815 

W A IT 

416 

1 

RADI 

INTP 

1.910569 

140201 

. OCOOO'- 

1 

0 

0 

0 

r 

c 

.910815 

NEWTSK 

341 

1 

EXTE 


1.910819 

140000 

. 0 0 0 0 o f 

0 

n 

0 

0 

0 

0 

.910815 

PR0CES 

341 

l 

EXTE 


1.910819 

140000 

.000000 

0 

0 

0 

0 

0 

0 

.910889 

Tfi ICGR 

341 

1 

EXTE 


1.910819 

140000 

.oooo r r 

0 

0 

0 

0 

0 

0 

.910889 

NEWTSK 

341 

1 

SUPE 


1.910889 

100000 

.OOOOOt 

0 

0 

0 

0 

r 

0 

.910889 

PRQCES 

341 

1 

SUPE 


1 .910889 

100000 

. OOOOOr 

0 

0 

0 

0 


0 

.911135 

ENDINT 

341 

1 

SUPE 


1.910889 

100000 

.OOOOOf 

0 

0 

0 

0 

( 

n 

. 95585C 

CFUINT 

291 

1 

RADI 


1 . 955850 

80101 

. ooooor 

0 

173 

1 

0 

t 

0 

. 95585C 

NEWTSK 

- 291 

1 

RADI 


1.955850 

80101 

. ooooor 

0 

17 3 

1 

0 

1 

0 

.955850 

PF0CES 

291 

1 

RADI 


1.955850 

80101 

. OOOOor 

0 

173 

1 

0 

1 

0 

. 955999 

TR IGGR 

291 

1 

RADI 


1.955850 

80101 

.000000 

0 

173 

1 

0 

1 

0 

.955999 

NEWTSK 

291 

1 

EXI0 


1.955999 

120000 

. OOOQOo 

0 

173 

1 

0 

1 

0 

.955995 

PR0CES 

291 

1 

EXI0 


1.955999 

120000 

. oooonn 

0 

173 

1 

0 

1 

0 

.956195 

TRICGR 

291 

1 

EX 10 


1.955999 

120000 

.oooorr 

0 

173 

1 

0 

1 

0 

.956195 

NEWTSK 

291 

1 

SUPE 


1.956199 

100000 

• oooooo 

0 

173 

1 

0 

1 

0 

.956195 

PROCES 

291 

1 

SUPE 


1.956199 

100000 

. ooooor 

0 

173 

1 

0 

1 

0 

.956445 

TR ICGR 

291 

1 

SUPE 


1.95619 9 

100000 

.ooooro 

0 

173 

1 

0 

1 

0 

.956445 

ENDINT 

291 

1 

SUPE 


1.956199 

100000 

.ooooor 

0 

173 

1 

0 

1 

0 

.956445 

CFUINT 

148 

1 

MWHP 


1.956449 

140209 

.oooo< 0 

0 

0 

0 

0 

0 

0 

.956445 

NEWTSK 

148 

1 

MWHP 


1 . 956449 

140209 

•OCOOOf 
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Summary Statistics 

When several systems are to be compared or studied, statistics on the 
utilization of the various components are useful. Data for these utiliza- 
tion statistics are maintained by the software operators and by the hardware 
models. In general, there is a set of summary statistics corresponding to 
each input group described in Section 6 An example of the output statis- 
tics for PR0GRAMS is shown in Table 6-3. 

Software Statistics . Total execution times are kept for each program 
model and also the number of times the program has executed (independent 
of the CPU on which it executes). Elapsed time is from the time the pro- 
gram starts until it executes a RETN, IDLE, or ENDINT operator. Processing 
time is maintained by the PR0CES operator. 1/0 delay is the time from the 
execution of a WAIT operator until the task is placed in the user specified 
scheduling queue. Interrupt delay is any time spent by the task in INTQ. 
Scheduling delay is time from the mark time stored in the task and the 
initiation of the task by means of a JUMPX or TRIGGER operator. The aver- 
age values are obtained by dividing by number of executions 

Hardware Statistics Each hardware group has certain associated 
utilization statistics. Processor utilization is given as percent of time 
idle, executing executive (PTYPE = 1) routines, and executing application 
(PTYPE = 2) programs. 1/0 channel utilization is given as percent of 
capacity as well as time for both burst and multiplex modes. The amount 
of data lost and individual line statistics are also given. Device con- 
troller utilization is split into percent of time transmitting data, waiting 
for interrupt service, and idle or control operations. The numbers of data 
transfer and control operations are also given. Device utilization percen- 
tages are for idle, control operation, access or latency, transmission, and 
interrupt servicing times. Total reads, writes, and control operations are 
given. 
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Table 6-3. C0MPSIM Program Output Statistics 


PROGRAM NUMBER 0F AVERAGE EXECUTION TIMES IN M I LL I -SECONDS 


NAME 

NUMBER 

EXECUTIONS 

ELAPSED 

PROCESSING 

1/0 DELAY 

SCHEDULING 

INT DELAY 

CPUPST 

6 

8 

.500 

.500 

.000 

628.099 

.000 

FALCHK 

10 

11 

.198 

.059 

• 000 

.460 

.000 

FALSCN 

12 

3 

8.335 

7.999 

• 000 

.892 

.336 

DACS 

£4 

B 

417.197 

50. 149 

• 000 

2.569 

• 804 

PBUPU 

29 

1 

128.600 

2.592 

• 000 

• 460 

• 000 

SLDTIM 

35 

8 

1.514 

1.514 

.000 

154.884 

.000 

THIPRO 

37 

1 

202.374 

1.530 

.000 

691.621 

.000 

TW0TEN 

38 

8 

202.074 

1.229 

*000 

98.310 

.000 

INTLOG 

49 

1 

714.181 

70.000 

.000 

71.484 

1 .398 

ALCONS 

50 

2 

6.166 

4.000 

.000 

170.806 

.000 

ALDISP 

51 

2 

158.254 

3.125 

.000 

87.049 

.000 

ALPROC 

52 

1 

460.108 

4.897 

.000 

118.299 

• OOO 

CIP 

54 

2 

1*157 

.649 

• 000 

164.709 

• 000 

DEFSEL 

63 

1 

.607 

.099 

.000 

128.561 

• 000 

PENT 

69 

2 

1*788 

.129 

.000 

293.567 

.000 

RETDIS 

72 

1 

143.445 

1.154 

.000 

61.299 

.000 

UPDATE 

76 

9 

51.067 

45.912 

.000 

178.402 

• 466 

INTSPR 

79 

1 

555.935 

30.000 

.000 

112.819 

.699 

LLM 

81 

1 

196.711 

19.999 

.000 

28.633 

.000 

MWHL0G 

82 

1 

910.375 

BO. 000 

.000 

919.073 

1 .24B 

VM 

83 

1 

140-782 

9.999 

.000 

28.633 

• 000 

DEHLOG 

84 

1 

597.310 

40.000 

.000 

174.657 

• 699 

LOGO 

87 

3 

63.859 

.999 

• 000 

127.776 

.000 

DA0UT 

89 

9 

766.262 

• 199 

.000 

199.373 

.000 

MWHPR 

SO 

1 

382.466 

30.000 

.000 

253.190 

.000 

MWHSPR 

SI 

1 

353.155 

30.000 

.000 

2432.566 

.000 

DLAPR 

92 

2 

574.001 

30.000 

.000 

793.469 

• 699 

CPNA 

110 

6 

131.141 

. 150 

.000 

26.935 

• 000 

SCHEDQ 

128 

30 

.761 

.000 

.000 

.000 

.000 

WAITO 

129 

55 

.084 

.000 

• 000 

33*078 

.000 

TELQ 

130 

34 

284.342 

• 250 

.000 

• OQO 

.000 

SLEEP 

131 

54 

• 206 

.070 

•000 

179.849 

•277 

PERSCH 

132 

8 

♦ 017 

.000 

.000 

.000 

• 000 

PSEXIT 

133 

96 

.000 

.000 

.000 

.000 

.000 

RADIO 

134 

402 

16.467 

• 188 

15*738 

.595 

• 013 

WAKEUP 

136 

54 

• 072 

.000 

.000 

.000 

.000 

RUNREQ 

137 

60 

.404 

.047 

*000 

.000 

• 357 

C3RUPT 

1 

28 

• 073 

.000 

• 000 

.000 

.000 

EXI0T 

1- j 

247 

.199 

.199 

• 000 

.000 

.002 

EXTENT 

140 

219 

.088 

.070 

• 000 

.000 

• 018 



User Outputs 

When a particular computer system is to be analyzed in detail, the 
standard outputs are usually not sufficient, and outputs tailored to the 
specific problems must be generated by the user. This is a reasonably 
simple task m C0MPSIM since program models can be written'in FORTRAN and 
have access to the entire simulation data base. Table 6-4 shows an example 
of output generated by a model of an 1/0 handler routine The program 

occupying each overlay segment at the beginning and end of each RAD (Rapid 
Access Device) access is printed out along with the RAD user and the number 
of entries in the various executive scheduling queues 
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Table 6-4. C0MPSIM User Output 


CT> 

I 

OJ 


time 

ACCESS 

RAD 

USER 

SEG 1 

SEG 2 

SEG 3 

SEG 4 






( 200 ) 

< 250) 

1 7501 

( 750) 

3 

•323068 

START 

1 

ALDISP 

CPUPST 


TWOTEN 

TWOTEN 

3 

.342254 

STOP 

1 

ALDISP 

CPUPST 


TW0TEN 

TWOTEN 

3 

.342403 

START 

1 

ALDISP 

CPUPST 


TWOTEN 

TWOTEN 

3 

•368150 

STOP 

1 

ALDISP 

CPUPST 


TWO TEN 

TWOTEN 

4 

» OOOOS 3 

START 

1 

SUPER 

CPUPST 


SLDTIM 

SLDTIM 

4 

.041974 

STOP 

1 

SUPER 

CPUPST 


SLDTIM 

SLDTIM 

4 

.287352 

START 

1 

SUPER 

DA0UT 


SLDTIM 

SLDTIM 

4 

.309211 

STOP 

1 

SUPER 

DAOUT 


SLDTIM 

SLOTIM 

4 

.309560 

START 

1 

SUPER 

DAOUT 


SLDTIM 

SLDTIM 

4 

.403443 

STOP 

1 

SUPER 

DAOUT 


SLDTIM 

SLOTIM 

5 

.078410 

START 

1 

SUPER 

DAOUT 


TWOTEN 

TWOTEN 

5 

.121410 

STOP 

1 

SUPER 

DAOUT 


TWOTEN 

TWOTEN 

5 

•121759 

START 

1 

SUPER 

CPUPST 


TWOTEN 

TWOTEN 

5 

.143619 

STOP 

1 

SUPER 

CPUPST 


TWOTEN 

TWOTEN 

6 

.000053 

START 

1 

SUPER 

CPUPST 


SLDTIM 

SLDTIM 

6 

•041974 

STOP 

1 

SUPER 

CPUPST 


SLDTIM 

SLDTIM 

6 

.287352 

START 

1 

SUPER 

DAOUT 


SLOTIM 

SLDTIM 

6 

.309211 

STOP 

1 

SUPER 

DAOUT 


SLDTIM 

SLDTIM 

7 

• 104840 
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1 

SUPER 
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TWOTEN 

TWOTEN 
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.147840 

STOP 

1 

SUPER 
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TWOTEN 
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intlog 
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DEHLOG 

dehlog 
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INTLOG 
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DEHLOG 

DEHLOG 
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INTLOG 
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DEHLOG 

DEHLOG 
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7.0 CANDIDATE PROCESSING SYSTEM CONCEPT 


An emerging concept for ground data processing is presented in this 
section. The concept is based on analysis and conclusions of study effort 
performed to date. Detail sizing and quantitative tradeoffs are yet to be 
performed to yield a refined system design. This iterative design work 
will be the subject of subsequent study activity and will depend heavily 
upon the System Performance Simulation developed m part under the current 
study. 

7.1 Requirements Baseline 

The intent in defining a candidate conceptual approach is to satisfy 
the following goals: 

• provide a focal design activity for a ground processing 
system(s) which would become operational in the post- 
Skylab era (i.e., 1975) and have utility continuing well 
into the shuttle era and potentially be supportive of a 
space station (i.e., extending at least to 1985) 

9 establish a system design baseline which provides a 
departure point for subsequent detailed design and 
the inclusion of emerging requirements and technology 

e provide a system concept that is predominately oriented 
to operational use of output products by user organizations 

This latter goal has a significant impact on design assumptions 
concerning overall information distribution and the diversity of required 
data products (principally reducing the diversity from that required by a 
pure experimental program). Implicit in this goal is the additional 
assumption that operational utility can in fact be achieved early in the 
shuttle era It is the repeated contention and position of this study 
effort that this operational payoff can, and must, be realized in this time 
frame. 

Given the above, the requirements baseline driving the system should 
be derived from the expected operational programs of the user agencies 
This is in sharp contrast to basing the system on an "experiments baseline" 
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such as the NASA "Bluebook" for Space Station. The analysis of user 
requirements performed within this study (fully reported in the Mid-Term 
Report and summarized in Section 3 0) provides the basis for the 
"Requirements Baseline" presented in Table 7-1 These requirements have 
been converted to an estimate of the raw input data volume necessary to 
drive the processing system. (Sections 7.4 and 7.5) 

7.2 System Concept 

The summary of requirements for data products and the estimate of 
input data volume support two contentions relevant to the selection of a 
candidate processing concept 

First - the diversity of useful data products for 
the management programs considered is not 
great The number of uniquely different 
product types is less than twenty as 
opposed to several hundreds or thousands 

Second - the overall input data volume required is 
only about 50 times greater than that now 
produced by the current ERTS A spacecraft 
covering the continental United States 
(digital data) 

These two contentions stem from the recognition that while the diver- 
sity of analysis and interpretive functions performed by users may be great 
(i.e., the subjective and complex rationale that the user goes through in 
using various data products), the diversity of the actual data products or 
interpretive aids is not great. This intuitively follows from the fact that 
there is a relatively limited number of methods and media by which infor- 
mation may be communicated to a human analyst (this being particularly true 
if the predominance of the information is derived from a single source type 
e.g., imagery). Additionally, it is recognized that for remote sensing 
technology a great deal of the required products for various management 
functions are based on the same image scene(s), a fact which minimizes 
greatly the total amount of input imagery required to support multiple 
programs . 


7-2 



Table 7-1. Requirements Baseline 



WINTER 

SPRING 

SUMMER 

FALL 

PHOTO MAP 

20 

28 

33 

18 

OVERLAY 

76 

98 

103 

66 

THEMATIC MAP 

51 

130 

75 

45 

SPATIAL MEASUREMENTS 

27 

42 

30 

21 

SPECTRAL MEASUREMENTS 

50 

70 

80 

47 

STATISTICAL SUMMARIES 

13 

34 

35 

9 

AUTOMATED INVENTORY 

40 

56 

47 

30 


AVERAGE UNIT PRODUCTION PER DAY FOR CONTINENTAL U.S. FOR SELECTED 
DATA PRODUCTS 





In view of the above, the first and most fundamental characteristic 
of the recommended system concept is that the processing facility(ies) be 
somewhat self-contained and service oriented. It may make sense to have 
a number of geographically dispersed facilities (location based primarily 
on convenience and efficiency of interface with user agencies being serviced) 
but each facility is envisioned as being autonomous m its production of 
data products. The facilities are therefore "centralized" at least with 
respect to respective "regions" served, and go beyond just preprocessing 
of data to the production of a family of data products. 

The centralized "service centers" would best be operated and managed 
by a single agency and would exist primarily to provide a service to the 
ultimate user and benefactor (e.g., U S.D.A , U S G.S., E.P A., NOAA, etc.). 
The individual user agencies would then either simply accept and consume 
the output data products without modification or subsequent processing, or 
in some cases they may require processing equipment within their facilities 
for subsequent specialized processing In this latter case, the intent 
would be to preserve compatibility between the processing systems of the 
service center and the agency facility, possible even to the extent of 
having compatible software systems and mterchangability of hardware modules. 
This overall service concept is illustrated in Figure 7-1. 

7.3 Processing Configuration 

Within each service center a processing configuration would be imple- 
mented based on the work station approach illustrated in Figure 5-10. 

Two major exceptions to this schematic would be considered for any near 
term design activity; both the Optical Processing Station and Electronic 
Analog Station would be eliminated. These two processing alternatives are 
currently considered to be either too embryonic or too inflexible to be 
viable alternatives. This is a tentative design decision and one which 
should be reviewed as technology in these areas progresses. 

The digital processing architecture of the central processing sub- 
system is currently envisioned as a single relatively large, general purpose 
um-processor (e.g , 360/75 or 1108) which is heavily supported by special 
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purpose, solid state processing modules These modules are seen as per- 
forming most of the high throughput processing for the major functional 
categories of; preparation and conversion, correction and classification/ 
recognition. 

The sizing of the digital processors and the exact split between 
conventional software and specialized "hardwired" processing will be the 
subject of subsequent simulation studies 

7.4 Data Storage and Distribution 

Data storage for the baseline concept is viewed as accommodating 
primarily short term retention of data for correction and calibration 
purposes. An early estimate of the number of separate images flowing 
through the facility is approximately 1800/week (100 n. mi. by 100 n. mi. 
frames, U.S coverage once per week, 6 spectral channels). This number 
of images probably sets an upper limit on short term retention for "system 
tuning" purposes and is well within practical capacity of conventional 
digital or hard copy storage mechanisms. 

Distribution of data products from the service center(s) to various 
user facilities is inherently no more demanding then the basic weekly data 
acquisition frequency. This would tend to indicate that conventional 
courier or mail service would be entirely satisfactory for timely dissem- 
ination. No operational requirements are seen for real time or electronic 
communication of data products from the servicing facility to the users. 

7.5 Onboard Implications 

The implications to onboard processing of the candidate concept are 
simply: 

• minimize the acquisition of unacceptable data (excessive 
cloud cover, etc ) and data not of interest, through 
adaptive collection techniques (either automated or man 
monitored, as in the case of the ERTS Operations Control 
Center at GSFC) 

• perform onboard corrections and calibration that are 
based primarily on subsystem induced distortion or 
errors 
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• compress the data prior to direct transmission to the 
service center(s) on the ground 

The baseline requirements (Table 7-1) convert to a total data acqui- 

11 6 
sition rate of about 3.0 x 10 bits/day (communication rate of 3 5 x 10 

bits/sec, 24-hour operation) which is well within the capability of current 

transmitting, receiving and recording technology, particularly if more than 

one satellite is used (e g , the weekly coverage requirement most probably 

would be obtained with two phased "ERTS" type sun-synchronous, 500 n. mi 

platforms) and more than one receiving service center is envisioned, as 

illustrated in Figure 7-1. 

7.6 Impact on Shuttle Missions 

The advent of the shuttle would have two ramifications to the candi- 
date concept; first, the shuttle as a launch and maintenance system for 
heavy automated payloads (i.e., about 7,000 lbs. into circular polar orbit 
at 500 n. mi.) would provide a significant payload increase over the 2,000 
lb. ERTS class payload, this in turn providing for essentially a longer 
life payload and increased resolution through accommodating heavier optical 
systems, and second, the "manned lab" possibilities of an earth observatory 
could greatly facilitate the desirable adaptive data acquisition techniques 
mentioned earlier. This latter possibility of a dedicated manned laboratory 
for earth survey onboard the shuttle is the primary area in which refine- 
ment of the candidate concept could impact both shuttle payload design and 
mission management for these earth resources "service" missions (Mote* the 
requirement for weekly frequency does not necessarily dictate continuous, 
uninterrupted coverage, and could conceivably be satisfied by 7 day sortie 
missions, end-to-end). 
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8.0 DATA PROCESSING ISSUES 


As this study progressed, a number of items outside of the study scope 
presented themselves as highly important in developing a total picture of 
the requirements for processing remotely sensed data The purpose of this 
section is to present discussions of selected topics of this nature 

8.1 Data Communications and Processing Distribution 

The mode of transmitting data among various points and the distribution 
of processing functions are basic areas of concern in formulating system 
design concepts. Although such considerations were beyond the scope of this 
study, some general observations have resulted from analysis of processing 
requirements. 

This study has established the fact that between the extremes of raw 
data and the results of analysis there is a definite set of data products 
which aid the analysis process. Furthermore, these products can be stan- 
dardized to a great extent. Therefore, the scope of considerations of 
communications must include 

• data acquisition (ground) 

0 development of interpretive aids 

o analysis 

• data archiving 

This study has relegated analysis to the users of the system as well 
as the development of .special i zed data products. For example, an important 
tool in geological applications is the tectonic map; conceivably a useful 
map product could be provided to the geologist with the identification of 
tectonic features left to him, the tectonic map is an example of a special- 
ized data product based upon a more general data product. 

In the material which follows reference will be made to "centralization 
of functions" and "distribution of functions," Centralization should be 
taken to include possibly more than one center, i e., there may be several 


8-1 



centers, but each is capable of producing a total range of data products. 

At least the following system concepts merit further consideration. 

• Super - APT - This sytem would represent an extrapolation 
of the current Automatic Picture Transmission capabilities 
of meteorological satellites. Data would be transmitted 
directly (either in real time or later - dependent on 
available, cost effective band width) to users. The users 
would be responsible for generation of data products and 
analysis. The users could archive the data, send all data 
to a central repository or send only selected data to a 
central repository. 

• ERTS/GDHS Denvati ve(s) - A central facility would be 
responsible for collecting raw data, performing cor- 
rections and providing imagery data to the user com- 
munity The user community would generate all imagery 
based interpretive aids and perform analysis Archiving 
would be accomplished in a separate facility. 

• Unified Center(s) - All functions related to generating 
standard data products would be co-located. The user 
community would be responsible for analysis Archiving 
would be performed in one facility. 

o Unique Functional Center(s) - A collection of centers would 
be responsible for generation of standard data products 
with particular functions assigned to individual centers, 
i.e., one center might have responsibility for conversion 
and preparation, another corrections, etc. 

All of these concepts must be examined from the viewpoints of economy 
and efficiency. As discussed in a later section, remote sensing will be 
competing with conventional data sources for a role m earth resources man- 
agement, therefore, considerable emphasis must be given to assessing total 
costs of the system from reception of raw data to delivery of the final 
data product into the hands of the user. Furthermore, attention must be 
given to the interrelationships of the many functions associated with 
handling of remotely sensed data. Preliminary consideration of these prob- 
lems has led to an initial bias in this study toward the Unified Center(s) 
concept As mentioned previously in this report, the initial goal was to 
identify the processing required, independent of where it was performed; 
as the analysis proceeded the unified concept demonstrated its viability. 
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8.2 On-Line Interaction 


The purpose of this section is to provide some general observations 
concerning the continuing role of man in the analysis of remotely sensed 
data The discussion is presented in two parts 

• the aspects of the technology in which limitations of 
automatic processes require manual intervention 

• those aspects for which man is uniquely qualified 

First, some background is necessary to set the stage for this discus- 
sion. The sophistication of man in analysis of imagery data must be con- 
sidered in two phases First, man is capable of rapidly combining spectral, 
tonal, textural, and spatial data into inferences concerning the contents 
of the image based upon a knowledge of cultural and physical patterns. 

Second, augmented with mathematical tools and appropriate instruments, 
man can infer many additional facts concerning the imagery using standard 
photo-interpretive and photogrammetric techniques. Of the former group, 
the most promising area for automation to date has been spectral signa- 
ture analysis. 

Formidable problems confront attempts to automate even this one area. 
Within a given scene the spectral signature can vary significantly from 
field to field of the same crop due to changes in illumination, planting 
practices (orientation of rows, distance between rows, etc.), differences 
in available moisture, and other factors. These problems while significant 
considerations within a scene, become manifold between scenes of a different 
locale and a different time. An immediate consequence is that in some sense, 
the classifier must be "trained" to recognize spectral signatures within a 
limited region of time and space. 

These difficulties have necessitated the use of ground truth. For 
clustering techniques the ground truth is used to assign points which "are 
close to each other spectrally" to categories. Other classification schemes 
make use of the statistical properties of elements of the imagery for which 
the category is known to classify the remaining points in the image. These 
methods can be combined by clustering and then classifying on the basis of 
class statistics. 
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Current classification systems make considerable use of man. Typical 
tasks of man are 

e identification of truth sites within the imagery 

e selection of training samples 

® monitoring of classification 

Identification of truth sites is highly important if precise knowledge 
of the sensor platform attitude and position is not known. In typical sys- 
tems with a poor position/attitude base, the input data is clustered and 
an operator identifies truth sites using a map containing identification 
of fields. 

Having located a truth site, it is necessary to select the sample 
spectral vectors which will be used to compute the classification statistics. 
This is typically performed by an operator using interactive displays. The 
operator may be required to monitor the effectiveness of the classification 
algorithm by noting its performance with respect to fields of known compos- 
ition which were not in the training set. 

All of the above discussion describes a somewhat straightforward 
process for agricultural fields which are basically "well behaved" i.e., 
essentially homogeneous. Wildlands present significantly more difficult 
problems, e.g., a statement that a region is forested with pine trees does 
not say that every resolution element will represent pine trees. 

Most of the roles described for man for current classification activ- 
ities could conceivably be automated with a certain degree of success 
assuming that the attitude/position base is well established - for "well 
behaved" cases . Beyond these cases it is highly unlikely that man's 
ability to identify using the many facets of data can be automated in the 
near future. 

In addition to the role of man m classification, two other major 
areas, registration and measurement of control points, which currently make 
use of man are worthy of consideration. Defining registration simply as 
"aligning one image with another" the different processes involved must be 
considered . 
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Alignment consists of first recognizing like features in multiple images. 
Displacements among the features must be recognized and some satisfactory 
adjustment made. In theory, through optical or digital correlation tech- 
niques, the first two functions can be totally automated. However, in 
practice manual assistance through the use of interactive systems is a def- 
inite benefit to the process. Man can rapidly detect like features in 
interactive displays, select appropriate points for measurements through 
zoom capabilities and relegate the measurement function to the computer. 

For control point measurements, once again, in theory, optical and 
digital correlation techniques can provide total automatic capability. 
Indeed, in the ERTS GDHS control point measurement is highly automated, 
but man performs a highly important role in selecting control points in the 
image which meet certain criteria As before, man is uniquely qualified 
for this role of noting immediately such conditions as the sharpness of the 
image in the regions of control points. 

Man will continue to perform an important function in on line monitor- 
ing of automated processes. Certainly, this will not involve monitoring 
every step of processing on every pixel, but periodic checks in the develop- 
ment of data products will undoubtedly be a necessity. Once again in many 
cases a glance at an intermediate product can accomplish a multitude of 
functions related to image data product quality, any portion of which would 
present major problems to automate. 

In addition to all of these, it must be recognized that photo inter- 
pretation is a highly developed science which requires many technical 
specialists. The very nature of many applications of remotely sensed data 
dictates that these specialists will be an important entity in any data 
processing center. 
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8.3 Data Archiving 

The data archiving problem was not specifically addressed in the 
course of this study, but certain issues in this area are naturally intro- 
duced in consideration of processing requirements The purpose of this 
section is to summarize the observations of this study concerning archiving 
requirements . 

First, a distinction must be made between short term storage and 
archiving. "Short term" as used here is that yet to be defined period of 
time in which data must be available to support operational analysis re- 
quirements. The bounding case of this category is data which must be 
available for change discrimination activities. Of the operational uses 
of remotely sensed data which were studied, a number which required change 
discrimination over a period of one week were identified. The interval 
over which changes are to be observed could extend to several years. For 
high frequency change discrimination activities, it would appear to be 
advisable to maintain files which are readily accessible. As the time 
interval between observations increases, the natural expectation is that 
penalties associated with restoration of data from archival media to 
readily accessible media would be tolerated. 

Two alternatives for change discrimination support present themselves: 

© First, the standard products of the processing center could 
be generated only on the basis of current data. Thus, the 
user agency would be responsible for the storage of past 
data (or data products) and the determination of changes. 

© Second, a procedure could be instituted which would retain 
in short term storage that data required for change dis- 
crimination as specified in the agreement with the user 
agency. 

Short term storage of certain data may also be required for calibration 
of instruments. Additionally, it should be anticipated that the processing 
of some imagery data may require corrective work after the data product has 
been examined by the user agency. 
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The archival requirements must consider the media, form and purging 
criteria for data. As indicated earlier, the media will probably be dic- 
tated by stability and physical compactness rather than rapid access. The 
form requirements are concerned primarily with the necessity of being able 
to precisely reconstitute original data. This latter consideration can be 
very involved as can be seen from the following example 

• An obvious archival requirement might be to store the 
classification of ground cover. Thus, all the spectral 
data collected in a given bounded reqion could be stored 
as "grass." The storage requirement could be re- 
duced from an extremely large number of observation 
vectors and associated ephemeris information to a sim- 
plified boundary description and the word "grass." 

However, if later applications require a comparison 
of the quality of the grass at five year intervals 
this simple descriptor is inadequate. Conceivably 
the storage of a sample mean vector and covariance 
matrix for the region would suffice for this problem. 

Considerable engineering judgement would be required in assessing 
individual requirements for form of storage. The same level of complexity 
exists for determining purging requirements. 

One of the strongest roles of remote sensing is the ability to iden- 
tify synoptic changes to a region at selected intervals. Thus, a natural 
reluctance to ever lose data is introduced. 

A possible, partial solution to the problems associated with archival 
form and purging is provided by a concept of tiered archiving, e.g., for a 
certain application it might be decided to retain raw data for one year, 
the classification statistics for that data for five years and an image of 
the region based on the data permanently - a three tier system. 

All that has been introduced here are certain problems associated with 
archiving; much work remains to be done. It is highly important that anal- 
ysis conducted in this area be concerned with all the ramifications of a 
variety of applications. Attention should be given to development of an 
archival system which is accommodative to individual needs. 
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8.4 System Flexibility and Growth 

A major problem confronting the design of a system for handling re- 
motely sensed data is that the precise functions to be performed by the 
system and the volume of input data and associated data products are unknown. 
The purpose of this section is to indicate the applicability of the fore- 
casting techniques developed during the study to deriving a suitable 
solution to this problem manifested in system design which is responsive 
to changes in requirements. 

First, it should be noted that if a limited role for the processing 
center is assumed, then accommodation to growth is rather straightforward. 
Given the functions to be performed the choice of equipments to handle 
changes in volumetric requirements gracefully is a standard design problem; 
albeit a very involved process. The primary difficulty is imposed when the 
range of processing functions is not specified. 

In the Mid-Term Report the concept of acceptance modelling was intro- 
duced as a modulator to processing requirements Simply stated, the accep- 
tance concept was an attempt to quantitatively describe the way in which a 
user agency would use remotely sensed data at various levels of availability 
of resolution, spectral range, automatic processing, swath and frequency of 
observations The concept provides a tool for addressing the problem of 
forecasting changes in processing requirements in the current condition of 
unknown data availability and use. 

The manner in which processing trends are established is discussed in 
the Mid-Term Report. Continued refinement of the acceptance values in that 
report coupled with realistic assessments of evolving data collection sys- 
tems would be very valuable in establishing trends against which require- 
ments for current systems could be evaluated to prevent designs which 
emphasize certain facets of processing at the expense of others. 
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The primary danger which is evident in the user requirements analysis 
is a concentration upon automatic classification techniques without atten- 
tion to more mundane roles of the system. This is a rather natural situation 
for the following reasons: 

• Automatic classification techniques require a great 
amount of effort to produce economically acceptable 
algorithms (in terms of speed and accuracy) 

® The U.S.D.A, is an agency pushing very hard to introduce 
remotely sensed data into its analysis chain, and many 
of the applications of this agency require automatic 
classification algorithms. 

However, there are many uses of this new technology which require 
data products that are not dependent upon automatic classification. Many 
of these applications do require considerable attention to geometric and 
radiometric fidelity with large requirements for photographic and plotted 
data products. A primary goal with respect to system flexibility should 
be to identify those requirements which do not hinge upon technology risk 
areas (e.g , automatic classification and certain spectral range availability) 
and to assure that these applications can be accommodated by the ground 
processing system. 


8.5 Econometric Considerations 

The purpose of this section is to highlight the importance of econo- 
metric considerations in the total remote sensing program. 

Three scenarios can be considered for the future remote sensing 
activities which have decidedly different econometric aspects The scen- 
arios are. 

• Experimental - Primary emphasis will continue to be upon 
development and refinement of remote sensing technology 
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• Discovery - Without any firm promise of return, early 
experiments in remote sensing show potential for 
dramatic breakthroughs in scientific knowledge or 
resource discoveries 

0 Operational - The technology is used to provide an 
additional or replacement data source to ongoing 
activities 

An assumption throughout the following discussion is that the pressure 
of scrutiny of Federal funding will essentially preclude the first two scen- 
arios as the dominant thrust of the Earth Resources Survey Programs. A 
successful program will need to push into operational applications. This 
particular scenario accommodates experimental and discovery functions, but 
the primary emphasis is upon support to critical earth resources management 
activities. 

This immediately places remote sensing in competition with conventional 
data sources, with the pressure emanating from the fact that the new tech- 
nology must at least provide the same information at a lower cost or a new 
capability at a marginally acceptable cost. An example developed by Ludwig 
Eisgruber at Purdue University helps to focus upon the criticality of these 
considerations . 

A major activity of the U S D.A is the forecasting by the Statisti- 
cal Reporting Service of various crops. Erroneous information on the 
expected size of a crop distorts optimal inventory carryover Eisgruber 
used an inventory adjustment model to compute the net loss in social bene- 
fit accruable to errors in forecasting yields of corn, soybeans and wheat. 
For these crops it is assumed that the forecast is made when production 
cannot be altered significantly in response to prediction about the quan- 
tity which will be available, but opportunities exist to adjust inventories 
and thus affect the price to be paid to the farmers. The following table 
summarizes the results of this analysis. 
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Estimates of Social Loss Due to Errors of Various 
Magnitudes in Crop Estimates Corn, Soybeans and Wheat 


Error of 
Estimate 

Social 

Loss Result! 

ng from Error of 

Estimate 

Corn 

Soybeans 

Wheat 

Total 3 Crops 

(percent) 



(million dollars) 

5 

32.1 

13 5 

24 8 

70 4 

4 

20 6 

8.7 

15 9 

45 2 

3 

11 6 

4.9 

8.9 

25.4 

2 

5 1 

2.2 

4.0 

11 .3 

1 

1.3 

5 

1.0 

2.8 


The net social benefit is computed by considering the true output, the fore- 
casting error, the equilibrium price and the price elasticity of demand. 

The production base for these data was the average production and prices 
for the 1966-1970 time period. 

Considering that for the foreseeable future remote sensing would 
probably have to show a major improvement in the cost associated with fore- 
casting, or improve the accuracy, the next concern is the current level of 
competency. This figure is set at 2% error. Thus the margin of net loss 
m social benefit associated with halving the current error is $8.5 M 
The scrutiny of the new technology will focus upon the cost associated with 
an effort which incorporates remotely sensed data, versus current costs (not 
accounting for a natural inertia to change) relative to changes in such 
figures as the net loss in social benefits. 

The considerations which enter such evaluations are summarized for 
the Agricultural Stabilization and Conservation Service compliance monitor- 
ing activities in Figure 8-1 Of prime importance relative to this study 
is the assessment of ground processing cost. Independent of decisions about 
distribution of processing functions, determination of the feasibility of 
remote sensing systems for a group of management functions must ultimately 
concentrate upon total ground processing costs, from receipt of raw data to 
delivery of a data product to the user. 
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Zl-s 


IN 

COMPLIANCE 

OUT OF 
COMPLIANCE 

DETECTED 

NOT DETECTED 

CONSEQUENCE 

X 



X 

IDEAL 

X 


X 


$ EXPENDED NEEDLESSLY IN FIELD 
CHECK, GENERAL ANNOYANCE 


X 

X 


IDEAL 


X 


X 

$ WASTED IN SUBSIDIES AND OVERALL 
EFFECTIVENESS, GENERAL ENCOURAGE- 
MENT FOR VIOLATORS 



Figure 8-1 Compliance Monitoring Cost Considerations 




@abs The author has identified the following significant results. Study 


ii ).i,,emphas is was on developing a unified concept for the required ground 
■ (system, capable of handling data from all viable acquisition platforms 
and sensor groupings envisaged as supporting operational earth survey programs. 

The platforms considered include both manned and unmanned spacecraft in near 

♦ 

earth orbit, and continued use of low and high altitude aircraft. The sensor 
systems include both imaging and nonimaging devices, loperated both passively 
and actively, from the ultraviolet to the microwave regions of the electromagnetic 
spectrum. 





